[ARCHIVE] Custom ZHLT by vluzacn

[vluzacn]

The latest update is Vluzacn's ZHLT v33 released on 2014/2/2.

v33 Details: http://forums.svencoop.com/showthrea...122#post498122
v33 Download: http://forums.svencoop.com/attachmen...chmentid=15666

Details of previous updates:
v31: http://forums.svencoop.com/showthrea...258#post496258
v30: http://forums.svencoop.com/showthrea...683#post488683
v29: http://forums.svencoop.com/showthrea...056#post486056
v28: http://forums.svencoop.com/showthrea...993#post485993
v26: http://forums.svencoop.com/showthrea...657#post482657
v25: http://forums.svencoop.com/showthrea...471#post476471
v23: http://forums.svencoop.com/showthrea...614#post463614
v20: http://forums.svencoop.com/showthrea...329#post461329
v17: http://forums.svencoop.com/showthrea...742#post452742
v16: on this page
v13: on this page


------------------------------------------------------------------------------------------------------------------



I am here to ask for advice for my custom version of zhlt, since I have noticed that there are also people working on zhlt here.
Note: my English is poor.

It is based on hlcsg, hlbsp in v3.4 and hlvis, hlrad in merl's version, and I carefully added in 'transparency.cpp' of v3.4 hlrad.

You can search for 'vluzacn' to find out all my changes in code.

Features:

1. opaque entities
Faster code in 'TestSegmentAgainstOpaqueList': by grouping opaque faces according to their model number.
No bugs in all procedures (direct, bounce), all kinds of light (point, sun, sky) and all vismatrix settings.
In hlcsg, added a flag to automatically copy all brushes of an opaque entity to world and retexture with 'SKIP', so it can chop solid faces.
Disabled reducing of facelight in semiopaque entities.
Fixed wrong opacity when light goes through edge of adjacent semiopaque face.

2. bounce light
Fixed bad assumption that 50% of light of a face must be send out to other faces, witch result in incorrect lighting when sky is used. Then 'SwapTransfers' procedure was removed.
Added a option to adjuct the precentage of light bounced, instead of the constant 50%.
Compress transfer data to cut down memory usage.

3. dynamic light
In gamma correction, consider dynamic light and static together (because in game, they are added without gamma).
Added support for multiple light_environments.
Coring preforms pre style instead of per light, and also performs in bounced light.

4. tricks for entities
Use 'zhlt_transform' key to scale(use its origin as center) or move an entity. Use '-scale #' option in hlcsg to scale the whole map.
Use 'zhlt_usemodel' key to delete model of this entity and copy 'model' value from another entity specified by the value of 'zhlt_usemodel'.
Text string in entity 'game_text' converts to UTF8 format.
You can alter the brightness of the sample under a mdl(such as 'cycler' entity) to fix incorrect brightness of mdl. Add key 'zhlt_copylight' to mdl entity, then lighting information will be copied from the sample under the target entity of 'zhlt_copylight' to the sample under the mdl.

5. compiling
Popup a console window if the compiler is not running in console.
Options can be setted in 'settings.txt'.

6. other features
Allow faces to be outside +/-4096 to build a larger map. Note, origin of visible objects (such as player, brush entity) should never be outside +/-4096.
Use textures such as 'nullnoclip' for advanced cliphull edit of brush.
Strip lightmap data of an entity if key 'zhlt_striprad' is setted.
Fixed sample position bug when a face is blocked but not chopped.


There are also many features that I intend to include in the future, such as special shadow for '{' texture, different bounce scale for different texture color, 'light_texture' entity, etc.



Please download from the link at the top. Don't download this older version: vluzacn.zip

[w00tguy123]

These tools have some pretty cool features. I also like how 'zhlt_usemodel' looks simpler to use than 'phlt_copy_brush' (super tools). I think I might switch over to these and experiment

Oh, and welcome to the forums!

[vluzacn]

Update:
version 13

Added entity 'light_shadow' to dynamically control the opacity of brush entity.
Example: Build an opaque entity (note: 'custom shadow' key is not allowed) and give it a name. Then place a 'light_shadow' entity with a name, and set the opaque entity as its target. Now, light blocked by the opaque entity will be added into the light_shadow's light style. You can switch the 'light_shadow' off/on just like normal lights to make shadow appear/disappear.('light_shadow' entity will be changed into 'light' in BSP file)
This feature affects bounce light unless option '-incremental' is set, and doesn't affect dynamic light with different style.

Fixed duplicate water texture for entity. Originally, brushes with passable content will generate mirrored copy for every face, so that these faces are visible from inside. But this causes the engine to draw twice when it comes to entity like func_water.
I have not tested it in mods other than cs. If this is not true, please tell me.

[goanna]

Welcome; looks like we have some more testing to do here. Improoved tools are always a plus! Thanks, we'll take a look.

[AdamR]

I am here to ask for advice for my custom version of zhlt, since I have noticed that there are also people working on zhlt here.
Note: my English is poor.

This is why ZHLT or SHLT or whatever we all want to call it now should be on Google Code, so anyone (approved) can contribute to it's future. They will give you SVN, a bug tracker, and a good amount of storage for free providing it's an open source project.

Contributors can be determined by using the 'create patch' tool, and approved for regular code committing by a leader if the patch is good.

[amckern]

So whats the compress do, and its 96, 48, 24, and 8 bit flags?

It compresses the light map data in the same way as vis compresses its map?

[vluzacn]

So whats the compress do, and its 96, 48, 24, and 8 bit flags?

It compresses the light map data in the same way as vis compresses its map?

It compresses every float number of transfer (contribution amount between patches for caculation of light bouncing)/ rgb float number as a whole (in -rgbtransfers) to reduce memory usage in the compiling process with extremely small loss of accuracy. Can not make BSP file smaller.

32,16,8 are available choices for the size of compressed data
32=no compress,
16=difference is less than 0.025%,
8=difference is less than 2%.

[amckern]

Ah ok, so its in part a memory optimization flag - how much is it effecting the overall speed?

[vluzacn]

Ah ok, so its in part a memory optimization flag - how much is it effecting the overall speed?

I think it will take up about 10 seconds for 1G transfers on MakeScales and every Bounce.

[vluzacn]

Update:
version 16
You can make all other vis leafs visible from a vis Leaf by placing an info_overview_point entity inside it. Useful for creating overview.
You can use ripent.exe to export and import texture data (when -parse is off)/ texture list and included textures (when -parse is on).
Calculate angle of light_environment which has 'pitch' or 'target' when writing to bsp, and set it to key 'angles', so it can be correctly recognized in the game. If you are using switchable or multiple light_environment, you can use entity info_sunlight(which will create a light_environment at end of entity list) to set angle and brightness manually.
You can assign areas that need to generate clip hulls, to reduce clipnode count. Create an info_hullzone entity that covers where players are allowed to go, then clip hulls of brushes that doesn't intersect with this entity will be stripped. This will not affect brush based entities and CLIP brushes, so enclose the map with CLIP if you encounter the leak error.
You can use '-smooth2 #' to set a smaller smoothing threshold for faces that are adjacent but have different textures.
Smoothing quality is enhanced. It calculates normals for every vertex.

[Qwerty]

Update:
version 16
You can make all other vis leafs visible from a vis Leaf by placing an info_overview_point entity inside it. Useful for creating overview.
You can export and import texture data (when -parse is off)/ texture list and included textures (when -parse is on).
Calculate angle of light_environment which has 'pitch' or 'target' when writing to bsp, and set it to key 'angles', so it can be correctly recognized in the game. If you are using switchable or multiple light_environment, you can use entity info_sunlight(which will create a light_environment at end of entity list) to set angle and brightness manually.
You can assign areas that need to generate clip hulls, to reduce clipnode count. Create an info_hullzone entity that covers where players are allowed to go, then clip hulls of brushes that doesn't intersect with this entity will be stripped. This will not affect brush based entities and CLIP brushes, so enclose the map with CLIP if you encounter the leak error.
You can use '-smooth2 #' to set a smaller smoothing threshold for faces that are adjacent but have different textures.
Smoothing quality is enhanced. It calculates normals for every vertex.

First and foremost -- the smoothing of the lighting is a very much needed and useful feature. Thank you very much! =D

Heh, if only these feature could be integrated into SHLT.

Would it be possible if you could remove the entity-limit protection from your compile tools? :? I get an error when compiling with yours and ZHLT (for sc_psyko) saying that the entity count is over the limit (but I do not get this with SHLT, probably because SHLT has the limits removed or increased).

[vluzacn]

Heh, if only these feature could be integrated into SHLT.

Why not?

Would it be possible if you could remove the entity-limit protection from your compile tools? :? I get an error when compiling with yours and ZHLT (for sc_psyko) saying that the entity count is over the limit (but I do not get this with SHLT, probably because SHLT has the limits removed or increased).

I have already raised MAX_MAP_MODELS, MAX_ENGINE_ENTITIES and MAX_MAP_ENTITIES.

[Silencer]

Why not?

If you don't mind me blatantly copying over some of your code as long as I give credit, I will do that.
Even better would be if we intercorporated our changes into one version together. The main advantages
of SHLT are 64-Bit and SSE2 releases, raised and tested limits, colored console output and Protector's brush copy entity.
All changes so far are tidily documented in the release thread's version history.

If you browsed the SHLT sourcecode for Protector, Silencer and amckern, you'd quickly have found all changes.

[AdamR]

Even better would be if we intercorporated our changes into one version together.

Did you guys even read that PM I sent you all a month or so ago? Finally at least one of you has realised this is the way forward.

For god sake get a damn space on Google Code or something and put all your code into 1 project.

They give you SVN for free with all the space you'd need for this project, a bug tracker similar to Mantis, and allows you to control who can contribute source code.

[AdamR]

What to?

MAX_MAP_MODELS should be no more than 400. Even though the engine can do up to 512, you have to make way for weapon models, monster models, other models, and sprites. Also the engine netcode can barely cope with 400 brush models as is so leave that one alone tbh.

MAX_ENGINE_ENTITIES and MAX_MAP_ENTITIES can be 4096 or something. We distribute Sven Co-op with 4096 entity slots, and afaik Silencer matched those in his SHLT.

[Qwerty]

I have already raised MAX_MAP_MODELS, MAX_ENGINE_ENTITIES and MAX_MAP_ENTITIES.

I am encountering this problem with your tools (as well as ZHLT) when trying to compile sc_psyko. According to LemonSoda, his map uses 512 entities (I haven't even opened his MAP/RMF to actually see -- I don't really plan to either).

[AdamR]

512 entities shouldn't be a problem :o even the WON HL1 engine can handle 800 map entities.

[Qwerty]

512 entities shouldn't be a problem :o even the WON HL1 engine can handle 800 map entities.

Erm, my bad. I must have remembered incorrectly.

I opened the map in Hammer, and the total number of entities is 1334.

3. dynamic light
In gamma correction, consider dynamic light and static together (because in game, they are added without gamma).
Added support for multiple light_environments.
Coring preforms pre style instead of per light, and also performs in bounced light.

om, I just totally have to say this. With this, it could be possible to make cheap night and day cycles. The only thing left of the "day and night cycle" picture is the skybox. If somehow there could be a dynamic skybox feature, or being able to change the skybox to a different one during the game without reloading the map . . .

Is it possible for Half-Life modifications to have such feature? Perhaps there could be two styles of dynamic skyboxes: crossfading and instant. Via entities, the mapper could set the duration between crossfades from the point of being triggered. Then, of course, if you set that duration to 0, it would be instant. This would be perfect for the OOT Project.

Also, is light_environment subject to the maximum lights per faces limit? :?

[AdamR]

The sv_skyname CVAR can directly choose a sky map. However it needs to be in the map config file as it is parsed after the entities are, and before players join the game. Changing this CVAR mid-map has no effect, most likely because the other sky you are trying to load is not pre-cached.

Implementing an entity that can change this CVAR is effortless, however all sky maps called by these entities would need to be pre-cached. I'm not sure if BMP/TGA files contribute to the 512 item limit, but each entity using a different sky to the worldspawn entity is going to want 6 or 12 items in it. Assuming other sky maps are not pre-cached is the only hurdle preventing sky hot-swapping, it could work.

We could also try using our new trigger_changevalue entity to directly alter the sky defined in the worldspawn entity mid-map if it doesn't crash the game.

light_environment is static afaik, so no it won't cause the "more than 4 light styles" warning (if this is what you're referring to). Only dynamic lights do that, which are light and light_spot entities that have a target name (to be switched on/off), rendering effect (flash/pulse/etc) or both. SHLT will find obsolete dynamic lights (those with no target name or rendering effect) and remove them.

[Qwerty]

Hmm, isn't the "maximum light styles per face= 4" a compiler limitation rather than a game limitation? I mean, if the light isn't animated/moving/FXing, the I don't see how it would be a problem to have 8 differently colored lights lighting a single brush.

[amckern]

http://code.google.com/p/zhlt - only thing is, i uploaded the 2.5.3 version, not 3.4 final as the base, and have run into trouble - i'll upload, and migrate 3.4 final, and then add the 2 projects from there.

Or i might upload version 16, and then add 3.8?

[Dynamite]

http://code.google.com/p/zhlt

Why did you select the Apache license?

[vluzacn]

If somehow there could be a dynamic skybox feature, or being able to change the skybox to a different one during the game without reloading the map

We can use textured entity or something to simulate skybox. Compiler can do something in this.

light_environment subject to the maximum lights per faces limit

Yes, if the light_environment is not static. And it is called maximum light styles, not maximum lights.

If you don't mind me blatantly copying over some of your code as long as I give credit, I will do that.

OK. Copy them as long as you think they are correct and necessary. Make sure you understand my code.
Note: My changes are based on csg,bsp of zhlt3.4 and vis,rad of custombuild1.7, so be careful.

Even better would be if we intercorporated our changes into one version together.

We should provide users alternative tools, since they can be buggy.

The main advantages
of SHLT are 64-Bit and SSE2 releases, raised and tested limits, colored console output and Protector's brush copy entity.
All changes so far are tidily documented in the release thread's version history.

I don't know what 64-Bit and SSE2 can actually improve.
My tools have a function that is same with Protectors's brush copy entity.

If you browsed the SHLT sourcecode for Protector, Silencer and amckern, you'd quickly have found all changes.

Why did I find nothing for 'amckern'?

Hmm, isn't the "maximum light styles per face= 4" a compiler limitation rather than a game limitation? I mean, if the light isn't animated/moving/FXing, the I don't see how it would be a problem to have 8 differently colored lights lighting a single brush.

It is a game limitation. Maximum 32 switchable light styles is also a game limitation.
Lights with same name or same FX are in the same styles, and all static lights are in the same styles too.

[AdamR]

Hmm, isn't the "maximum light styles per face= 4" a compiler limitation rather than a game limitation? I mean, if the light isn't animated/moving/FXing, the I don't see how it would be a problem to have 8 differently colored lights lighting a single brush.

It's only a warning, not an error. I get this on polar rescue. The only issue with it is you may notice slight oddness to some of the lighting edges where the other light styles kick in, and as you said barely noticeable if the lights are not animated. It's nothing major and often something only someone as pedantic and petit as me will pick you up on.

http://code.google.com/p/zhlt - only thing is, i uploaded the 2.5.3 version, not 3.4 final as the base, and have run into trouble - i'll upload, and migrate 3.4 final, and then add the 2 projects from there.

Or i might upload version 16, and then add 3.8?

Nice
Could you add me please, my Google account is ukAdamR.

[Silencer]

Why did I find nothing for 'amckern'?

That's odd. You should.

All the nice tweaks of both of our tools aside, if there was something that would have highest priority on both of our tools, it would be fixing random clipping planes sometimes missing or going wrong, causing players to fall out of map etc.

64-bit tools give an about 20% faster compile on 64-bit machines/OS.
SSE 2 architecture uses doubles instead of floats, causing compilation to be slower, but more precise.
This would sometimes fix odd errors for me, but by far not always.