[ARCHIVE] Custom ZHLT by vluzacn

[vluzacn]

As you can see, the light_environment lights models properly under both compilers, and the VHLT even lights the skylight more accurately. But the glowing water light does not light models at all under VHLT. Given that monsters on this map are more often lit by just glowing water than they are lit by sky, this be a problem.

Models can not be lit by light. They are only lit in two ways:
(1)light_environment
(2)the lightmap of the ground surface(it has to be a world face, entity faces don't count) under the model.

So your problem is the ground did not get enough light. The reason is VHLT removed the back face of water surface in order to fix the engine's bug of draw both side of water at the same time. As a result, the water surface no longer emits light downward.
This can be solved by the next update of VHLT by allowing water surface to emit light downward.
Or you can manually add the back faces (create a brush, texture the bottom side with !liquid and other sides with SKIP, so the brush becomes a single water surface facing down, then add it to func_water).

[Thothie]

Okies... So I changed the water texture...
[before] [after]
Changed the info_texlight entry to full white, but kept the adjusted VHLT brightess (255 255 255 7500)...

...and now it r taking forever to compile... I suspect the result is going to be a full-bright green map. (Plus, the water the original mapper was after more "this water is a bit off" rather than "OMGZ Step in this and you dies!!11!", I suspect)

I shall report on progress when compile is done... Although I'm very tempted to stop it, knock down the brightness, and restart, as the current ETA is over 80 minutes, vs. the usual 15-20mins, and like I said, I ain't got all day to fiddle with this.

Another mapper is fiddling with it as well... He got a bright blue !water texture to light models, but he noted that, while his water was extraordinarily bright, the light on the model was very modest.

He also noted he had to bump up his non-water textures brightness up to 100x to get them to light in some cases. (this one for instance, normally lights that whole area @ 255 128 64 200 [in SHLT like so], and he had to bump it up to 10000 to get this effect.)


I'll fiddle with scaling the textures by the gates, but one is already a 256x256 texture scaled to 0.5... Guess I'll try 0.1, and see if I can see the shadow - though it'll make the floor look a bit odd.

[Thothie]

Models can not be lit by light. They are only lit in two ways:
(1)light_environment
(2)the lightmap of the ground surface(it has to be a world face, entity faces don't count) under the model.

I take it, this is some new limitation in VHLT, as all these snow boars, are sitting on func_walls that emit light (save the white one, under the light, to demonstrate normal color). Said func_walls are only painted on top - the rest is null. This was compiled in SHLT.

That'd be a rather critical limitation, as light sources are quite often func_illusionary, func_wall, or func_water, and/or on the floor.

Now... I could compile this same map in VHLT... But... This damn thing is still compiling the sewer map... More news as it happens...


edit: After running three of my four cores at 85 degrees for 3hours, 41 minutes, and 25 seconds (an all time record compile time on any CPU I've ever had)... We got... Well, I dunno what we got, Half-Life won't load it (Chunk error). >< - BSP viewer will, however, and the result is a bright green map (although not quite so bright as I expected - but still, brighter than I wanted). I can't tell if models will light in that water, because the map wont load... So... Yeah, not worth going through this again. Just going to get this patch out now.

[AdamR]

Would you know why these compilation errors happen Vluzacn?

writebsp.cpp:534

		dplane_t *mp = &g_mapplanes[i];

Error 1 error C2065: 'g_mapplanes' : undeclared identifier


qbsp.cpp:1378

				plane_t *mp = &g_mapplanes[i];

Error 2 error C2065: 'plane_t' : undeclared identifier
Error 3 error C2065: 'mp' : undeclared identifier
Error 4 error C2065: 'g_mapplanes' : undeclared identifier


qbsp.cpp:1380

				VectorCopy (dp->normal, mp->normal);

Error 5 error C2065: 'mp' : undeclared identifier
Error 6 error C2227: left of '->normal' must point to class/struct/union/generic type
Error 7 error C2065: 'mp' : undeclared identifier
Error 8 error C2227: left of '->normal' must point to class/struct/union/generic type
Error 9 error C2065: 'mp' : undeclared identifier
Error 10 error C2227: left of '->normal' must point to class/struct/union/generic type


qbsp.cpp:1381

				mp->dist = dp->dist;

Error 11 error C2065: 'mp' : undeclared identifier
Error 12 error C2227: left of '->dist' must point to class/struct/union/generic type


qbsp.cpp:1382

				mp->type = dp->type;

Error 13 error C2065: 'mp' : undeclared identifier
Error 14 error C2227: left of '->type' must point to class/struct/union/generic type


qbsp.cpp:1389

			if (q_filelength (planefile) != g_numplanes * sizeof (dplane_t))

Error 15 error C2065: 'plane_t' : undeclared identifier
Error 16 error C2070: ''unknown-type'': illegal sizeof operand


qbsp.cpp:1393

			SafeRead (planefile, g_dplanes, g_numplanes * sizeof (dplane_t));

Error 17 error C2065: 'g_mapplanes' : undeclared identifier
Error 18 error C2065: 'plane_t' : undeclared identifier
Error 19 error C2070: ''unknown-type'': illegal sizeof operand


I'm guessing the root cause is plane_t and g_mapplanes not being declared. VL20 compiled fine.
Simply adding #include "..\hlcsg\csg.h" did help, but did not entirely cure. It just throws a bunch of unresolved externals:


Warning 1 warning C4005: 'BOGUS_RANGE' : macro redefinition csg.h 110 hlbsp
Warning 2 warning C4005: 'BOGUS_RANGE' : macro redefinition csg.h 110 hlbsp
Error 3 error LNK2005: "struct dplane_t * g_dplanes" (?g_dplanes@@3PAUdplane_t@@A) already defined in qbsp.obj bspfile.obj hlbsp
Error 4 error LNK2019: unresolved external symbol "struct plane_t * g_mapplanes" (?g_mapplanes@@3PAUplane_t@@A) referenced in function "void __cdecl ProcessFile(char const * const)" (?ProcessFile@@YAXQBD@Z) qbsp.obj hlbsp
Error 5 error LNK2001: unresolved external symbol "struct plane_t * g_mapplanes" (?g_mapplanes@@3PAUplane_t@@A) writebsp.obj hlbsp


Also HLRAD fails to build due to these issues:

Error 7 error LNK2019: unresolved external symbol "struct radtexture_t * g_textures" (?g_textures@@3PAUradtexture_t@@A) referenced in function "void __cdecl MakePatchForFace(int,class Winding *,int)" (?MakePatchForFace@@YAXHPAVWinding@@H@Z) qrad.obj hlrad
Error 8 error LNK2001: unresolved external symbol "struct radtexture_t * g_textures" (?g_textures@@3PAUradtexture_t@@A) trace.obj hlrad
Error 9 error LNK2019: unresolved external symbol "void __cdecl LoadTextures(void)" (?LoadTextures@@YAXXZ) referenced in function _main qrad.obj hlrad
Error 10 error LNK2019: unresolved external symbol "void __cdecl AddWadFolder(char const *)" (?AddWadFolder@@YAXPBD@Z) referenced in function _main qrad.obj hlrad

[vluzacn]

Would you know why these compilation errors happen Vluzacn?

Yes I know. 'Release' mode compilation doesn't have these errors. For other modes, I forgot adding a macro definition.

Also HLRAD fails to build due to these issues:

Error 7 error LNK2019: unresolved external symbol "struct radtexture_t * g_textures" (?g_textures@@3PAUradtexture_t@@A) referenced in function "void __cdecl MakePatchForFace(int,class Winding *,int)" (?MakePatchForFace@@YAXHPAVWinding@@H@Z) qrad.obj hlrad
Error 8 error LNK2001: unresolved external symbol "struct radtexture_t * g_textures" (?g_textures@@3PAUradtexture_t@@A) trace.obj hlrad
Error 9 error LNK2019: unresolved external symbol "void __cdecl LoadTextures(void)" (?LoadTextures@@YAXXZ) referenced in function _main qrad.obj hlrad
Error 10 error LNK2019: unresolved external symbol "void __cdecl AddWadFolder(char const *)" (?AddWadFolder@@YAXPBD@Z) referenced in function _main qrad.obj hlrad

They are compiled in the new 'loadtextures.cpp'.

[AdamR]

Yes I know. 'Release' mode compilation doesn't have these errors. For other modes, I forgot adding a macro definition.

What macro is this?
Also I doubt that would fix the unresolved externals? They are now down to:

Error 3 error LNK2005: "struct dplane_t * g_dplanes" (?g_dplanes@@3PAUdplane_t@@A) already defined in qbsp.obj bspfile.obj hlbsp
Error 4 error LNK2001: unresolved external symbol "struct plane_t * g_mapplanes" (?g_mapplanes@@3PAUplane_t@@A) qbsp.obj hlbsp
Error 5 fatal error LNK1120: 1 unresolved externals \bin\Release\Win32\hlbsp.exe hlbsp

They are compiled in the new 'loadtextures.cpp'.

Added to HLRAD project, though I had to do 2 fixes to make it compile.

Around line 84:

		if (!dir)
		{
			Error ("Can not find wad file '%s'.\nPlease add parameter '-waddir \"\"'.", name);
		}

Needed to be inside the while loop, or it would be undefined.

Around line 269:

		if (!wad)
		{
			Warning ("Texture '%s' (%dx%d): texture is not found in wad files.", tex->name, tex->width, tex->height);
			DefaultTexture (tex, tex->name);
			return;
		}

Also needed to be inside the while loop, or it would be undefined.




Edit: I've actually got all this to compile. I'm going to check the map first, but if it works I'll post the entire source folder I have for a comparison.

I have come across a massive problem with the loadtextures in HLRAD though. It seems to read the WAD files list from the map worldspawn entity, but it does not take into account the full paths defined in the WAD configuration. Because only one -waddir can be specified, this makes it impossible to have WAD's in different folders. Going to attempt to modify this to read the WAD configuration instead (if defined).

Alternatively this can be fixed by not trimming out WAD paths (by removing definition HLCSG_STRIPWADPATH) until after the RAD process has finished. This is the simplest fix.

[AdamR]

Something is badly screwed when I compile the map, it's at BSP stage and I suspect it's to do with all the double planes malarky. Pic related

Edit: Switching off HLCSG_HLBSP_DOUBLEPLANE fixed everything.

[vluzacn]

What macro is this?
Also I doubt that would fix the unresolved externals? They are now down to:

Seems you have messed up the source files. Try to use the original source and import the dsw file and compile.

Added to HLRAD project, though I had to do 2 fixes to make it compile.

Around line 84:

		if (!dir)
		{
			Error ("Can not find wad file '%s'.\nPlease add parameter '-waddir \"\"'.", name);
		}

Needed to be inside the while loop, or it would be undefined.

Around line 269:

		if (!wad)
		{
			Warning ("Texture '%s' (%dx%d): texture is not found in wad files.", tex->name, tex->width, tex->height);
			DefaultTexture (tex, tex->name);
			return;
		}

Also needed to be inside the while loop, or it would be undefined.

Need to move the definition out of the loop instead.

Edit: I've actually got all this to compile. I'm going to check the map first, but if it works I'll post the entire source folder I have for a comparison.

I have come across a massive problem with the loadtextures in HLRAD though. It seems to read the WAD files list from the map worldspawn entity, but it does not take into account the full paths defined in the WAD configuration. Because only one -waddir can be specified, this makes it impossible to have WAD's in different folders. Going to attempt to modify this to read the WAD configuration instead (if defined).

Alternatively this can be fixed by not trimming out WAD paths (by removing definition HLCSG_STRIPWADPATH) until after the RAD process has finished. This is the simplest fix.

There are no such problems and don't need any fix.

[AdamR]

I have come across a massive problem with the loadtextures in HLRAD though. It seems to read the WAD files list from the map worldspawn entity, but it does not take into account the full paths defined in the WAD configuration. Because only one -waddir can be specified, this makes it impossible to have WAD's in different folders. Going to attempt to modify this to read the WAD configuration instead (if defined).

Alternatively this can be fixed by not trimming out WAD paths (by removing definition HLCSG_STRIPWADPATH) until after the RAD process has finished. This is the simplest fix.

There are no such problems and don't need any fix.

... well it happens to me right now.

A while back we requested if HLCSG could strip out the full path names from the "wad" line in the worldspawn entity, which you did for us. In my case it would remove all the "\Users\Adam Reece\Applications\HL1Dev\textures\somefolder\somewad.wad" into just "somewad.wad" ... 8 times

The problem now is that HLRAD needs to read the map's WAD files, and it does this by looking at them in the same "wad" line. Without the paths present it can never find the file, which is why I've now moved the code to strip out the paths once HLRAD is complete rather than HLCSG.

You gave us the option to fix this by specifying -waddir to HLRAD, but that is only 1 folder. WAD configurations allow us to have WAD's in any folder we like, so HLRAD will need to too. We don't need HLRAD reading the WAD configuration, just HLCSG not stripping out the full paths -- let HLRAD do it once it's finished.

I've already fixed this if you'd like my changed file.

[vluzacn]

... well it happens to me right now.

A while back we requested if HLCSG could strip out the full path names from the "wad" line in the worldspawn entity, which you did for us. In my case it would remove all the "\Users\Adam Reece\Applications\HL1Dev\textures\somefolder\somewad.wad" into just "somewad.wad" ... 8 times

The problem now is that HLRAD needs to read the map's WAD files, and it does this by looking at them in the same "wad" line. Without the paths present it can never find the file, which is why I've now moved the code to strip out the paths once HLRAD is complete rather than HLCSG.

You gave us the option to fix this by specifying -waddir to HLRAD, but that is only 1 folder. WAD configurations allow us to have WAD's in any folder we like, so HLRAD will need to too. We don't need HLRAD reading the WAD configuration, just HLCSG not stripping out the full paths -- let HLRAD do it once it's finished.

I've already fixed this if you'd like my changed file.

You can add as many '-waddir' as you want. This is similar to '-wadinclude'.
I recommend that you set '-waddir' to the HL folder and mod folder, and this can be done by editing 'settings.txt' once you install the compiler. Custom wads should either put into these HL folder and mod folder or be included into .bsp, since you have to do this before map testing after all.
Also as a principle, hlrad should not change any entity keyvalue, because otherwise hlcsg '-onlyents' compile will break.

[Thothie]

Success!

Took three mappers trying to follow your SKIP brush instructions in various ways in tandem, but after much trial and error, we got this. Encasing the !water brushes entirely in SKIP brushes seems to release the light within. I needed to use -texreflectscale 3.0 to light up the room proper, and still needed to use a brightness of 2500 (vs. SHLT's 75 for the same effect), and it kinda "leaks" light where the SKIP brushes meet (as you can kinda see there where the water turns the corner)... and the models are still quite a bit dimmer than I'd like them to be. But they aren't buggy black, so I'll call it success.

...and, compiling with three different systems at once here, we still managed to get the patch out on time.

Now, in regards to the old quote:

Models can not be lit by light. They are only lit in two ways:
(1)light_environment
(2)the lightmap of the ground surface(it has to be a world face, entity faces don't count) under the model.

With the -texreflectscale at 3.0, the result is more or less what you thought it'd be... (Although also hugely bright, but the walls are fairly pale...)


However, without the texreflectscale...


It looks much like the SHLT compile. So... Maybe, without odd settings, it seems to work better than you thought it would. Maybe something about the non-standard texreflectscale causes the model lighting to bjork more severely than it otherwise would. Although the models were coming up black before we added the textreflectscale flag, so I'm not sure...

(Also, here's the source [+lights.rad entries] for the "lighttest" boxmap, with the func_wall lighted floor tiles, though it isn't Half-Life friendly, entity wise.)

In anycase, for all your help, after consulting with yet three other mappers (none of which are of the aforementioned group - and four if you count myself), I have their approval to donate their map sources to you all.

While it is true that we often convert maps for use with Svencoop, it tends to take time for someone to pick up the interest to do so. So here's the map sources to be converted by any Svencoop member or fan that may wish to do so. I've included the lights.rad entries (not all of which are in the info_texlight entities), the versions of VHLT used to compile them, and batch files containing the settings. I've also included wad files to save the effort of extracting the textures from the maps:

http://www.thothie.com/msc_dev3/deraliasewers.rar - Deralia Sewers, by "Dridje" and "Joe!"
http://www.thothie.com/msc_dev3/the_wall1-2.rar - The Wall by "Skillasaur"

The_Wall1&2 can be merged into one map in obvious fashion - they were, in fact, originally one map, but our mod (which shall remain unnamed for sake of politeness) is very, very buggy, so it was split in two to encourage stability.

So modify and use those as you see fit. I'm sure the original mappers wouldn't mind getting credited though. The sewer map might not be too far out of place in Sven, though The_Wall has more of our standard MORPG look.

TL;DR: It worked, free map sources for Svencoop conversion linked above as reward.


PS. Back to the subject at hand, I've not had any of the wad-finding issues that AdamR describes, but I am using the -waddir function in the settings.txt (also included). I've also got all my wads in one shallow folder. Having it otherwise tended to mess with older versions of ZHLT (as does having a space in your path, or an "@" sign, as pointing to your wad files inside some Steam installs might cause - so my advice is to do the same.)

[AdamR]

Got your VL23 code compiled and working Vluzacn -- I see you've done more lighting fixes, my light_spot's are producing light with less black patch problems (nearly none at all now).

I do have an issue though. In the screen shot, the room in the white border does not get compiled correctly. It's the newest room in the map. The room has some buttons in, and the room itself is there and working, but all the textures inside are null'd out. I can no-clip to the room and walk inside, and use the buttons (as I know where they are).

I thought this could be because I was exceeding MAX_MAP_TEXTURES, so I changed just a few to get me down to 511. The map compiles fine, but didn't fix the issue. I compiled my custom ZHLT 3.4 code to allow more than 512 textures (as it claimed I had 513 in the map rather than 511 yours did), the map compiled fine, but more importantly ran fine in game -- nothing null'd out.

Edit: This happens on VL20 too.

Do you have any idea what could be causing this? Here is the final BSP memory chart (ignored HLRAD stage)

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
models            298/512        19072/32768    (58.2%)
planes           6628/32768     132560/655360   (20.2%)
vertexes        35959/65535     431508/786420   (54.9%)
nodes           14876/32767     357024/786408   (45.4%)
texinfos         1899/32767      75960/1310680  ( 5.8%)
textures          498/512          498/512      (97.3%)
faces           26955/65535     539100/1310700  (41.1%)
clipnodes       26198/32767     209584/262136   (80.0%)
leaves          10256/32767     287168/917476   (31.3%)
marksurfaces    36419/65535      72838/131070   (55.6%)
surfedges      126122/524288    504488/2097152  (24.1%)
edges           63104/262144    252416/1048576  (24.1%)
texdata          [variable]    2061028/33554432  ( 6.1%)
lightdata        [variable]          0/33554432  ( 0.0%)
visdata          [variable]     843552/2097152  (40.2%)
entdata          [variable]     326881/524288   (62.3%)
498 textures referenced
=== Total BSP file data space used: 6113677 bytes ===

That "texttures 498/512" line is one I added if you want it for your own code.

[vluzacn]

I do have an issue though. In the screen shot, the room in the white border does not get compiled correctly. It's the newest room in the map. The room has some buttons in, and the room itself is there and working, but all the textures inside are null'd out. I can no-clip to the room and walk inside, and use the buttons (as I know where they are).

This is the a new feature in hlbsp that removes all rooms that contain no point entity or brush entity's origin.

That "texttures 498/512" line is one I added if you want it for your own code.

Nice. If MAX_MAP_TEXTURES is an engine limit, I will make it a new line too.

[AdamR]

This is the a new feature in hlbsp that removes all rooms that contain no point entity or brush entity's origin.

Ah okay, that sounds fair actually. No point in keeping a room that has no way of a player or NPC using ever seeing/using it. I'll just slap in an info_target.

Nice. If MAX_MAP_TEXTURES is an engine limit, I will make it a new line too.

I'm not sure if it really is a limit. I had over 512 textures with my custom 3.4, and the map ran fine. I'll put in more textures and test if any don't show up.


Also, are you interested in putting ZHLT on an SVN repository so we can all sync and compare code changes? It's actually pretty simple to use. I'm sure Silencer and possibly amckern may have code contributions. It'll also help us keep a tab on bugs.

[Silencer]

Btw, does RAD have lightstyle priorities? E.g. toggleable lights with varying brightness values of 50, 100, 150 and 200 hit a patch (more than 4, because of default lights), tools would omit the one with a brightness of 50, because it has least visual relevance/impact, instead of skipping the one which would exceed the limit.

[BlueFeena]

Trying to make compile tools "smarter than a human" sounds like an outrageously bad idea.

RAD: "Hey, I know more about mapping than you do, so instead you fixing a problem on your own because you may have designed something for a specific reason, let me just neuter a few entities for you."

[Silencer]

I wasn't talking neutering light entities, but neutering lightstyles hitting a patch. If I have 3 dynamic ass-large headlights and one dynamic mediocre lightbulb, I'd prefer the ass-large headlights to be of greater priority where they intersect lighting on a patch with the normal lightbulb. Alternatively: Dithering, but unsure how that'd look.

[BlueFeena]

What if I want the lowered power light to have priority? Maybe it's a color that I badly need to show up in the map.

[Silencer]

What if I want the lowered power light to have priority? Maybe it's a color that I badly need to show up in the map.

My method is still preferable to random behaviour; also I'm just asking.

[Thothie]

Have you fiddled with it yet? The HLRAD is so very different in VHLT, I wouldn't be surprised if it let you put more than 4 light styles on a face already.

[Silencer]

The lightstyles-deal is an engine limitation unfortunately. 4 are quite sufficient, but the old tools sucked at handling the situation of exceeding the limit, and I'm asking if vluzacn touched that.

[Qwerty]

The lightstyles-deal is an engine limitation unfortunately. 4 are quite sufficient, but the old tools sucked at handling the situation of exceeding the limit, and I'm asking if vluzacn touched that.

Would be better if dynamic lighting was an option, then that would virtually eliminate the 4 lights per face limit so long as you used dynamic lights and/or after reaching the limit. Games ought to be based on the philosophy that everything is naturally dark / unlitten, and then work from there via dynamic lights. (EDIT: Yes, I know that if you put one light in the map, the rest of the map will be dark because of HLRAD).

Just like Natural Selection 2, yes?

[Thothie]

I don't think you'd be able to initiate a dynamic light from the map side, without a corresponding entity in the mod. (In our unnamed mod, we've made a few scripts for that.)

Plus, dynamic lights are entity/edict intensive, vs. light maps.

That, and the rather simple dynamic lights, provided by the engine, don't cast shadows. I suppose you could make one that does (roughts of ruck), but I don't even want to think about the GPU/CPU performance hit... Maybe something for the SOHL crew. (Man, I wish they would have made it easier to cut out bits of their code and apply them to your mod.)

[w00tguy123]

Dynamic lights are possible right now btw. Just set the effect keyvalue of any entity to 4 or 8. You can't change the brightness or color of these lights, but they're generic enough to work for many scenarios.

[Thothie]

If you mean a light that cycles or flickers, that is indeed possible, but that's still just multiple lightmaps, I do believe - and those do cast shadows, but they also count against the limit.

True dynamic lights, however, is in reference to those that are created at game time via entities, such as the glow rockets make, or the flashlight glow. I don't think you can designate those via default Half-Life entities, save maybe the xen plant entity (can't remember the name of it - the little stalk thing that winks out and retracts when you get near it). Those lights are created client side and cast no shadows - but also, presumably, don't count towards the 4 light styles on a face limit.