Reducing Clipnodes with zhlt_usemodel Templates
As one creates bigger and more complex maps, one of the limits one might encounter is the Max Clipnode Limit (32,767 in vanilla GoldSrc). Roughly speaking, each solid face within the playable volume of a map gets its own clipnode, per
. If one is well below the entity budget but reaching the clipnode limit (often the case in mods/games with increased entity limits), this is a method for trading in those entity slots to save up on clipnodes.
VHLT introduced the zhlt_usemodel
keyvalue for use in entities. The behaviour is different between brush and point entities, but for brush entities it will essentially clone the brush model of the entity specified in the value of this key, along with its lightmaps, decals, and importantly for this guide: its collision model.
This means that for every clone using zhlt_usemodel
, it only ever use a single brush model slot and only the clipnodes generated for the original template, at a cost of one entity slot per clone.
Now one could already optimise a lot of a map using this by itself, but it has certain drawbacks. For instance, any decals applied to one brush model is instantly copied to all the clones, including decals such as bulletholes and blood splatter added during gameplay. Lightmaps are also copied, which might not be desirable in environments with non-uniform lighting.
directly also limits one to only clone the same object, but if a CLIP template
was used instead one could re-use the same collision model for any object of a similar size, and leave these objects as non-solid func_detail
By creating a "collision model" using CLIP brushes (i.e. brushes covered in only CLIP texture) and tying it to a named func_wall
, it becomes what I like to call a CLIP template
This can be cloned and used as the "collision model" for any object of roughly the same size across the map without expending any clipnodes apart from those making up the original template. As these cliphulls are invisible, and "perceived at a lower resolution" than any visible geometry, there is some leeway with what one can get away with.
Using these CLIP templates one get to save up on the clipnodes and
avoid the drawbacks of using zhlt_usemodel
directly, such as shared decals and lightmap.
On the other hand it has its own drawbacks that are worth mentioning.
As mentioned at the beginning, it's a trade-off of entity slots for clipnodes. If one has already used up the entity budget for the map, this is not a viable solution.
It also is only usable for static objects. It cannot be used with func_breakable
, for example.