- Joined
- Jul 7, 2011
- Messages
- 504
- Reaction score
- 109
Hello everybody,
I've just been experimenting a bit with an entity that's exclusive to vluzacn's modified version of Zoner's Half-Life Tools v3.4, also known as ZHLT v3.4 VL30 or "VHLT" in short. This entity is called func_detail and it is the best entity ever made. Ever.
What is it? A func_detail is a brush-based entity that does not cut into the BSP structure (= less wpoly = higher r_speeds = better map performance) but it does block light/cast shadow -- like you'd generally want solid objects to do.
Big deal, you can use a func_wall and play around with the "ZHLT Lightflags" Attribute to achieve just those effects, right?
But here's the thing that makes func_detail the best entity ever: It's actually not an entity! Upon completion of the map compile, they're not counted as entities, and if you view your map in BSP Viewer, func_detail doesn't even show up in the entity list. They render fine (and infact still render even if you disable entity rendering) and, like I said, block light yet don't cut worldbrushes. They do cut each other (like func_wall entities cut each other) but that's no big deal really.
I'd like to quote vluzacn here:
What I want to emphasize is: func_detail is amazing. It's the best entity of all time. I really am running out of superlatives to describe how incredible this thing is.
A map like bloodrose could probably save over 60 or even over 70 entities by converting (most) of the func_wall to func_detail.
I'll upload comparison pictures later.
P.S.: Mappers who examine the zhlt.fgd that comes with ZHLT v3.4 VL30 will probably feel like kids walking into candy stores (lots of awesome entities in there). Try it!
I've just been experimenting a bit with an entity that's exclusive to vluzacn's modified version of Zoner's Half-Life Tools v3.4, also known as ZHLT v3.4 VL30 or "VHLT" in short. This entity is called func_detail and it is the best entity ever made. Ever.
What is it? A func_detail is a brush-based entity that does not cut into the BSP structure (= less wpoly = higher r_speeds = better map performance) but it does block light/cast shadow -- like you'd generally want solid objects to do.
Big deal, you can use a func_wall and play around with the "ZHLT Lightflags" Attribute to achieve just those effects, right?
But here's the thing that makes func_detail the best entity ever: It's actually not an entity! Upon completion of the map compile, they're not counted as entities, and if you view your map in BSP Viewer, func_detail doesn't even show up in the entity list. They render fine (and infact still render even if you disable entity rendering) and, like I said, block light yet don't cut worldbrushes. They do cut each other (like func_wall entities cut each other) but that's no big deal really.
I'd like to quote vluzacn here:
vluzacn in the ZHLT v3.4 VL25 changelog said:Add 'func_detail' entity, which is similar in function to the func_detail in Source, though I probably implement it in a rather different way.
What is func_detail:
(Brushes that are not in any entities are called world brushes, and brushes in func_details are called detail brushes.)
Detail brushes are almost same to world brushes. They cannot be distinguished from world brushes once the compile has finished. For example, when viewing the bsp with 'BSP Viewer', func_details don't disappear after unchecking 'render entities'.
What makes detail brushes different from world brushes is that they don't participate in visibility calculation, which means they won't slow down hlvis.
A better description can be found here: http://developer.valvesoftware.com/wiki/Func_detail
Differences between detail brushes, world brushes and func_walls:
Compared to world brushes, detail brushes don't block vis or slow down vis process, and don't chop faces from world brushes, and don't cause the 'Ambiguous leafnode content' warning.
Note that detail brushes cannot be used to seal a map, and must not be made of water or sky (but SKIP and CLIP can be used in func_details).
Compared to func_wall, func_detail don't consume engine's model precache slots (which is 512 max), and will give player mdl (and any other mdl) correct brightness when he steps over it.
In addition, there is an option that allows a func_detail to chop faces of world brushes in order to reduce face area and produce better lighting.
But unlike func_wall, the faces in func_detail will be cut if it happens to span across a splitting plane of the BSP structure generated from world brushes and func_details, thus increasing bsp file size and wpoly.
Usage:
Convert any brushes, that are not parts of the basic structure of the map, to func_detail. They cannot be water brushes or sky brushes.
You can leave 'Detail level' to 1. For tiny objects, you might set it to 2, so that they won't chop the faces of other func_details.
For large shapes such as terrain and walls, you can set 'Lower its level to cut others' to no less than its detail level, so that they can chop adjacent world brushes like world brushes.
Before compiling the map, hide all entities and func_details, make sure there are no leaks and the structure is good enough for vis calculation.
Further explanations:
To add the feature of detail brushes, I introduced a concept called 'detail level', which is a number assigned to each brush, which can be 0, 1, 2, 3,... .
--I will refer to all brushes that have the same detail level as a 'layer':
All world brushes are in the layer of detail level 0.
All brushes in a func_detail go to the layer corresponding to the func_detail's 'detail level' which is default to 1.
Brushes in brush entities such as func_wall are not in consideration here, because they are in seperated entities.
--In the CSG process:
Every layer will not be affected by any more detailed layers (with only one exception).
Every layer will be chopped by all less detailed layers. That is, if a brush in this layer is embedded into less detailed layers, then the embedded part will be chopped off.
Brushes in the same layer always chop each other.
The exception is, if you want a brush from a more detailed layer to chop the faces of a brush from a less detailed layer, you can either set the former's 'Lower its level to cut others' or the latter's 'Raise its level to get cut' to no less than the difference of their detail level.
--In the BSP process:
First, the surfaces of the layer of detail level 0 split the space into large leafs, which are also portal leafs that are used in vis calculation.
And the layer of detail level 0 is not allowed to have leaks, so detail brushes cannot be used to 'seal' a map.
Then the surfaces the layer of detail level 1 split every leaf into smaller leafs, but they no longer act as portal leafs.
Then does layer of detail level 2, 3,... .
Note that number of visleafs reported in the bsp statistics chart is the number of final leafs generated by all layers.
--In the VIS process:
The visibility data is calculated only according to portal leafs generated by the layer of detail level 0.
So, func_details will not increase the time of VIS process significantly. But they may have some impact on the VIS process, because when the BSP program is processing the layer of detail level 0, it has to also try to optimize the total number of faces, nodes and leafs.
After the calculation, the vis data between portal leafs is then converted to the vis data between final leafs. So adding func_details will increase the total size of vis data.
Other notes:
The detail layers uses an advanced method to decide leafnode content, so detail brushes will not cause "Ambiguous leafnode contents" warnings and related problems.
Usually merely using detail level 0, 1 and 2 is enough. Using too many detail levels may make the BSP process inefficient and increase the bsp file size. For the same reason, 'Detail level of cliphulls' should always be 0 or 1 unless you are trying to solve some cliphull errors by adjusting this value.
Changing the 'Detail level of cliphulls' to 0 will reduce the number of clipnodes, but the cliphull of this func_detail will not use the new leafnode content method.
vluzacn said:Too many small world brushes will slow down the VIS part in map compiling a lot and often increase face number since they cut intersecting faces. Typically, you solve this problem by converting them into func_walls. But converting to func_walls also has some negative effects, including consuming model slots (you will get PF_precache_model_I error if you have too many brush based entities), less effective VIS optimization (which means that the whole func_wall will be rendered if any part of it is visible to the player), and sometimes incorrect color of player model when a player steps on it. Func_details are good substitute for this kind of func_walls because they don't have these issues.
What I want to emphasize is: func_detail is amazing. It's the best entity of all time. I really am running out of superlatives to describe how incredible this thing is.
A map like bloodrose could probably save over 60 or even over 70 entities by converting (most) of the func_wall to func_detail.
I'll upload comparison pictures later.
P.S.: Mappers who examine the zhlt.fgd that comes with ZHLT v3.4 VL30 will probably feel like kids walking into candy stores (lots of awesome entities in there). Try it!