View Full Version : The ultimate quick-guide to less clipnodes

03-05-2009, 12:02 PM
The ultimate quick-guide to less clipnodes

The limits of leafs and clipnodes have always been the most annoying to all mappers.
Since with the new compile tools we are now more free with the leaf-limit, the clipnodes
limit is the only one left that really blocks the mappers' way to much bigger and more
complicated maps than we have seen before.

I tried increasing the limit in the compile tools, to test if going over the limit can actually be
handled by the engine, but ocassionally some brushes are not solid, and you can fall outside map.

I want mappers to try this low clipnodes-guide, not only so they can make their maps bigger, but also
because too many clipnodes in one place can actually stress the game server really much, especially
with many monsters around which require lots of CPU-capacity for pathfinding and the little thinking they have.

In order to achieve lower clipnodes,
there are 5 major methods to use:

The CLIP-Special-Texture.

A brush with the CLIP-Texture will overwrite any clipping information inside it and set it to clip.
Clipping exists on 2 levels:

Solid world brushes. (World clip brushes don't affect clipping information of brush entities)
Brush entities. (Clip brushes can be applied to brush entities - they will only affect the applied entity then)

Then again, clipping parts into 2 types:

Collision hull: What blocks players and monsters.
Wall: What blocks bullets and dropped ammo/weapons. This second type requires much less clipnodes, and therefore shall not be of relevant interest in this guide.

The -cliptype HLCSG parameter.

-cliptype legacy: The old cliptype, which still is used as default, but is buggy.
-cliptype precise: About 18% less clipnodes than you currently have with great increase of clipping quality. (most recommended)
-cliptype smallest: About 15% less clipnodes than you currently have with horrible clipping quality. (not recommended)
-cliptype simple: About 20% less clipnodes than you currently have with great increase of clipping quality, but with one disadvantage:

Players are shifted up a bit on sloped ground.

-cliptype normalized: Less than 3% less clipnodes with minimal clipping improvement.

The zhlt_noclip keyvalue.

If applied and set to 1: All collision hull information is stripped from the entity. However, if the entity is not designated to have its clipping information stripped (E.g.: func_illusionary), it will still block bullets and everything which falls into the collision category of these.
If applied and set to 0: Collision hull information will be applied. Warning: If set on a func_illusionary, collision hulls will explicitly be calculated for the func_illusionary, but not work in game. Doing that you actively waste clipnodes.

The new phlt_copy_brush entity which comes with the new compile tools.

Disadvantage: When decals appear on one existence of an appearance, they will appear on all of its clones as well. This is a general disadvantage of this entity which has nothing to do with the amount of clipnodes. Just mentioning.

Ask yourself: "Does this really have to be that complex/be here?" on every detail in your map.

From the above, the first method to try is the -cliptype parameter. Not only does it lower
clipnodes, but also it does improve clipping, so there are less places to get stuck on.

The next method, which you should even use when you have plenty of clipnodes left to use,
is clip brushes. Principally you put clip brushes on complex details which are likely to cause
many clipnodes. If that detail is an entity, you must add the clip brush to the entity, other-
wise your clip brush will be calculated within the solids' world. If you are using railings or any
other similar solid-rendered structures which one is meant to be able to shoot through, but
not walk through, tie the assembly of clip brushes which make the collision hull to an entity
and add a null textured brush, so the map will still compile. The effect in game will be same,
but if clip brushes are tied to an entity (funy_wall is fine), they won't interfere with the world
clipping unneccessarily, which causes more clipnodes. Of course you can only do this when you
have left some capacity on the model limit.

Anyway, it is a fact that often people use the clip texture wrong and then end up wondering why
they hit the clipnodes limit even faster. You can learn how this works by trial and error. Make a
clip brush, save and export to map, compile. You can already see the final amount of clipnodes
after HLBSP is done with BSP Generation. You don't have to wait till HLVIS is done. Basically, the
CLIP-Texture is simply overused most of the time. When putting a clip brush around a detail,
make sure to wrap the detail into the clip brush as tight as possible. Don't have any parts
of the clip brush protrude. Even if its just a simple pipe, adding a rectangular clip brush
will lower clipnodes.

The phlt_copy_brush method is pretty much self explanatory. Making clones of an existing appearance will
obviously not create any additional clipnodes. However, the game engine will have to calculate
the clones' taken appearances' hulls as well.

The zhlt_noclip keyvalue can reward you with especially surprising results. Many details aren't reachable
for the player, so you can simply strip the clipping information. The fun fact is, that the object will
still block bullets. Just as a side-note: When you are standing inside such an object and shoot, the
bullet will fly out of it. That way the detail will still appear as if it was actually there. However, if you
are very close to the clipnodes limit, you can still make those details func_illusionaries and maybe
lay a null-textured func_wall rectangle over the detail, to at least retain a bare illusion of solidity.

If all the above methods do not help, there is only the chance of simply removing details or making
these less intense, and ultimately, your map smaller.

Hope this helps, even if 90% of the people will skip the long text and only try the -cliptype parameter. :clean:

04-05-2009, 06:30 AM
I'd really like to know why -cliptype precise often bugs the whole clipping of my map, creating invisible walls and making some walls non-solid. This only happens when I use sloped brushes that are angled in all three dimensions, and almost always if I use brushes like that. Any ideas how to prevent that from happening, or do I just have to settle with a less precise cliptype?

04-05-2009, 09:46 AM
-cliptype precise makes everything MUCH better for me. It attempts to make as many collision hulls convex
as possible, which naturally results in less getting stuck. Never had problems with invisible walls when -cliptype
precise was set. It's the opposite, it'd fix invisible walls. I don't see why you would need brushes which are sloped on
all three dimensions. If you use those as ground to walk on it should cause massive stucking with the default legacy
cliptype as well. Try using -cliptype simple. Make sure that all your brushes are valid, and try moving them around
a bit, changing their position and relation and hence maybe fixing the problem out of luck.

EDIT: I by the way tried doing more than 32767 clipnodes: Some brushes will not be solid at all anymore, and you
can fall outside world.

04-05-2009, 11:44 AM
A brush as simple as that causes the problems: http://a1win.pp.fi/ss/half-life/hammer/svencoop/sc_frostfire0001.jpg

In a simple room it doesn't get bugged, but in a large area with other complex architecture it does. Oh well it's not just the one brush.

Somehow it seems to affect the vis leafs too or something. I'll post a video in a moment.

Here: cliptype-precise-bug.avi (http://a1win.pp.fi/video/svencoop/cliptype-precise-bug.avi) (44.8 MB)

The first part of the video is with normal cliptype (no -cliptype parameter used), and there are no problems. However, there would be if I hadn't simplified some architecture (of the moving iceblocks), which is why I'd rather use "-cliptype precise" if I could. After the death the video shows the map compiled with "-cliptype precise" parameter, nothing else changed. Strange things happen... All the brushes are "valid" and their corner points are on the grid.

I had the same problem with one of my TFC maps, also a big room with lots of sloped brushes, until I changed the complex cliffs around the area to simpler ones.

04-05-2009, 12:25 PM
Those brushes might be invalid solid structures. Note that the invalid solid structure detection of VHE is not perfect at all.
You should remake those sloped brushes with triangles, concave, then try to recompile and see if -cliptype precise still gives
you that. And when making those into triangles, make sure each triangle is its own brush, or you'll end up with coplanar
plane errors.

04-05-2009, 04:08 PM
Mmh yeah I guess the compile tools can get confused with non-triangle brushes even though they are seemingly valid ones. But anyway, compile tool bug. :p

I'll start doing them as triangles anyway, would be nice to get my moving iceblocks not crush the players.

04-05-2009, 04:18 PM
The iceblocks not crushing players is fixable. You only have to rebuild them as one convex brush.
That can be some work since VHE has no feature to freely add and remove vertics to/from an existing brush.
I really want the sourcecode of VHE 3.5b.

04-05-2009, 04:40 PM
It does. Select 2 vertices and press Ctrl + F.
edit: Nvm, it keeps crashing if I add them too freely.

It's made of 2 brushes atm, I might try making it just 1... Anyway I've fixed it so that the actual visible part is a func_illusionary setorigined to the func_train, which isn't sloped on Z axis at all. It makes bullets hit the air if you try to shoot through the "corners" though but it's not too bad atm.

04-05-2009, 05:32 PM
You can make that much nicer and easier, imho. o.o

09-04-2013, 03:07 PM
-cliptype precise: About 18% less clipnodes than you currently have with great increase of clipping quality. (most recommended)

this might be an outdated information, as it just gave me 5% extra clipnodes.

clipnodes 29736/32767 237888/262136 (90.7%)
without, and with:

clipnodes 31429/32767 251432/262136 (95.9%)

Map: HL/OpFor Portal
Compilers used: VHLT v23 with adam's changes