Clipnode count?

[J-M v2.5.5]

Is there anyway to figure out how many clipnodes there are in a map? The compile log tells me many things but not how many clipnodes I have...

And what's the difference between the "legacy" and "precise" cliptype parameters? The ZHLT website tells me that they're the "old" and "new" methods of cliptype calculation, respectively, and that of course is worthless information. What the hell is that supposed to mean? Old and new methods? Seriously.

Select the clip hull generation method. Choices are smallest, normalized, simple, precise or legacy (default).

The ExpandBrush function of HLCSG has been reworked to fix 2 bad assumptions that led to "sticky" exterior corners in Half-Life maps.

To use the new clip hull feature, use "-cliptype precise". If you want to same some clipnodes, you can use "-cliptype simple" which will shift player models a few units upward on sloped floors. If you want to use the new HLCSG for the speed improvement but want the old style clipping, use "-cliptype legacy". If you want to have the smallest possible number of clipnodes and don't mind some stickyness (not recommended), use "-cliptype smallest". "-cliptype normalized" uses bugfix 1 and skips bugfix 2 for people who don't want denormalized brushes.

 

[Thothie]

ZHLT won't report it itself, lest you hit the limit - but I suspect if ye looked at the ZHLT source, you could get it to do so.

Meanwhile, use count_ents:

c:\hldev>count_ents islesofdread2


Entity Counter by XP-Cagey, v1.0 (Feb 25 2006)
Based on code by Valve Software

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
models            235/400        15040/25600    (58.8)
planes          10310/32767     206200/655340   (31.5)
vertexes        14916/65535     178992/786420   (22.8)
nodes            7822/32767     187728/786408   (23.9)
texinfos         1092/32767      43680/1310680  ( 3.3)
faces           11184/131071    223680/2621420  ( 8.5)
clipnodes       27408/32767     219264/262136   (83.6)VERY FULL!
leaves           5539/8192      155092/229376   (67.6)
marksurfaces    15399/65535      30798/131070   (23.5)
surfedges       48293/512000    193172/2048000  ( 9.4)
edges           27111/256000    108444/1024000  (10.6)
texdata          [variable]    5163856/4194304  (123.1)VERY FULL!
lightdata        [variable]    2845038/4194304  (67.8)
visdata          [variable]      73911/2097152  ( 3.5)
entdata          [variable]      96449/524288   (18.4)
=== Total BSP file data space used: 9741344 bytes ===

A lot of the data count_ents gives isn't entirely accurate, though, as some of it changes in-game due to the nature of the entities. Clipnodes, however, change very little, and rarely in any way of consequence.

As for the differences in the clip methods, it's just different calculations used to minimize expanding planes and to correlate collision detection. Frankly, for all the ZHLT's praises of the other modes, I tend to find Legacy is the least likely mode to do strange things, and only use the others (starting with -precise then -simple) when I start hitting that clip node wall (although, generally, there are better ways to avoid it.)

-legacy = Ye old standard (Default)
-precise = Builds from the hull inward, increasing vis nodes, but reduces clip nodes (sometimes causing no-clip)
-simple = Merges a lot of clipnodes, but causes shifting, which may cause your head to get stuck in sloping caves
-smallest = Desperation: further reduces clip nodes, but sometimes results in funktastic invisible geometry
-normalized = Same as smallest, but is more likely to discard funktastic brushes (which may result in no-clip walls.)

If you have no funktastic brushes (ie. you can import your own .map file, and get no discarded brush errors), you can get away with any of these modes, and may even prefer -precise. However, most mappers have at least a few funktastic brushes on their map (islesofdread2_JM, for instance, has 264 of them), and the clipping structure for these is much more likely to be discarded, and thus the brush become "walk-through-able", under any cliptype save -simple and -legacy.

The tricks to reducing clip nodes (and thus avoid dealing with this mess to begin with):
- Player clip any empty areas the player is not intended to be able to reach
- Use clip brushes to simplify collision detection of all complex geometry (you can go further by func_illusionary'ing the thing inside the clip box) - this is especially useful with cones and cylinders.
- Merge/uniform boxy areas (such as jutting castle buttresses) by placing clip brushes in the empty spaces.
- If using the hack-and-slash method for natural cave walls, retain the areas you would carve out, and turn them into clip brushes instead, thus the resulting wall will be square, though it will still appear to be "nook and crannied".
- Very small clip areas (such as radial logs around a camp fire) should be covered with a single clip brush, as generally, that's the effective space the player can actually climb.

Some of those tips also aid in monster navigation and reduce the likelihood that players will get stuck on stuff. While you can make your walls and such look as complex as you like, it's always best to make sure the actual collision area is as simple as possible, even if it means covering all your fancy walls with foot-thick clip brushes.

 

[J-M v2.5.5]

islesofdread2_JM, for instance, has 264 of them

-
- Is this a lot?
- Probably sticky edges from the hole / sea areas, right?
- Is this bad? I rarely got 'semi-stuck' in the hole / sea areas during playtesting. There is some stickyness, but it is minor.

*list'o'tricks*

I know all the tricks and I went through all of them on a certain map of mine which is just rediculously big. It refused to compile until I used -cliptype precise but I have yet to play the map to see if anything screwed up.

 

[Thothie]

islesofdread2_JM, for instance, has 264 of them

-
- Is this a lot?
- Probably sticky edges from the hole / sea areas, right?
- Is this bad? I rarely got 'semi-stuck' in the hole / sea areas during playtesting. There is some stickyness, but it is minor.

It's not *terrible* but it depends largely on the reason for discardment... The .map file loads fine, so I think, in this case, it's mostly brushes being discarded from the hull because they are not visible from the inside. Whereever you have stickiness, however, there is no doubt room for improvement.

*list'o'tricks*

I know all the tricks and I went through all of them on a certain map of mine which is just rediculously big. It refused to compile until I used -cliptype precise but I have yet to play the map to see if anything screwed up.

I was just noting, for insance, where you player clipped each log in isleofdread2 front fireplace, individually, you likely created more clipnodes rather than reduced them. It would have been better to have placed a single bounding box around all the logs, as they are so small, the player isn't likely to notice the difference in navigation.

 

[J-M v2.5.5]

So I compiled this one map with the precise cliptype instead of the legacy one, and not only do I have way less sticky edges, the clipnodes usage went from too much (over 100% usage) to 70.5%. I didn't notice any non-solid worldbrushes either. I guess I'll be sticking to this cliptype from now on, it's really not as bad as you made it seem

 

[Thothie]

None of the modes are *terrible* - provided your brushes are uniform, but none are as forgiving as Legacy. Also make note of the number of discarded brushes at the top of your HLCSG report.

I think ms_snow uses -simple, and wicard oven uses -precise, neither suffers much from it (although if you use -precise on ms_snow, there's spots where you'll actually fall through the floor!)

Aleyesu (of Rickler make) also uses -simple, for he hit the wall quite early with that ambitious layout. -precise resulted in some corners of the cave being partly noclipped.