Updated Hlcsg Fixes "sticky" Corners

Cagey · February 2003

<div class="IPBDescription">Oops, I did it again ;)</div> Hopefully the controversy over the MAX_MAP_PLANES fix has died down enough for this to be well received...

I've reworked the ExpandBrush function of HLCSG to fix 2 bad assumptions that led to "sticky" exterior corners in Half-Life maps. I've sent the source in to Merl for inclusion in future builds, and am making the updated code available here for people interested in getting an immediate fix. The new exe is backward compatible with all previous versions of the tools and includes the raised plane limit from 1.7p. This exe requires the same DLL that the 1.7p build requires, which you can find in the webbed tool thread. In addition to the bugfixes, I've also sped up the CreateBrush part of HLCSG by around 75%.

A summary of how this works can be found at <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>http://xp-cagey.com/articles/clip_hull</a> for those who are interested in knowing what's changed.

To use the new clip hull feature, download the attached HLCSG and add the following switch: "-cliptype precise". If you want to save some clipnodes, you can use "-cliptype simple" which will shift player models a few units upward on sloped floors but create fewer nodes. [NOTE: The marine model is currently drawn a few units off the floor when standing, even using the old HLCSG. This can be verified by looking at the marine model on any standard NS map from the 1.0 distribution.]

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".

I've included a small test map that exhibits both of the bad assumptions from the old code in the zip file. All of the files in the webbed thread have also been updated.

<span style='color:red'>EDIT 3/13/03: Posted version 1.7p4 which fixes recursive threadlock error and uses different method to determine directions that planes face--new method works better with "thin" brushes and many concave brush shapes. New version also includes a fifth -cliptype, normalized, which has fix #1 everywhere, and fix #2 turned off. This copy of HLCSG requires some microsoft dlls to run properly. You can grab the first one <a href='http://www.cyscape.com/download/msvcr70.dll' target='_blank'>here</a>. If you still can't get the tools to run, two people have reported needing a second DLL you can grab from <a href='http://www.dll-files.com/dllindex/dll-files.shtml?msvcp70' target='_blank'>here</a>, but others seem to be OK without it.</span>

EDIT: clarification <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>
</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'>
-cliptype legacy ? (default) (Classic clipnodes, classic sticky corners) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (no fixes, all like old)
-cliptype precise ?(Some new clipnodes, no sticky corners) ? ? ?(clipnodes could go up or down) ? (both fixes on walls and ceilings)
-cliptype simple ? (All new clipnodes, no sticky corners) ? ? ? ? ? ?(fewer clipnodes than precise) ? ? (both fixes everywhere)
-cliptype smallest (All new clipnodes, some sticky corners) ? ? ? (fewest clipnodes) ? ? ? ? ? ? ? ? ? ? ? ?(fix #2 everywhere, fix #1 turned off)
1.7p4: -cliptype normalized (Some new clipnodes, some sticky corners) (clipnodes could go up or down) (fix #1 everywhere, fix #2 turned off)
</td></tr></table><span class='postcolor'>

EDIT: the version posted here is out of date -- you can find the latest downloads in <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=21248&st=0' target='_blank'>this thread</a>.

Ollj · February 2003

aah
at least I know what a hullfile and clipnodes exactly do.
excelent description mister cagey.

less clipnodes, les stuck places, less hanging on corners as skulk.
hopefully...

-rest deleted-

Cagey · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Feb 21 2003, 11:44 AM)</td></tr><tr><td id='QUOTE'> I dont understand the difference between "-cliptype precise" and "-cliptype simple"  </td></tr></table><span class='postcolor'> 
Both precise and simple use unnormalized brush expansion (bugfix #2) for walls, but precise turns it off for floors. Basically, with "-cliptype precise" you get floors that are the same as with the old HLCSG, but with "-cliptype simple" players will be several units higher off of sloped floors when you play the game. "-cliptype simple" also results in fewer final clipnodes than "-cliptype precise". Both simple and precise fix the normalization bug for walls and ceilings--the only difference is for floors, which don't need the fix because of the engine's code for moving players up steps.

Ollj · February 2003

as I understood:
-deleted- better explained my XP...
You confused me...

Cagey · February 2003

Yeah, I guess it could be confusing... "simple" uses only the new technique, "precise" uses the new for walls and ceilings and the old for floors... I named it simple because precise uses both types of clipping, but I see where it could be confusing--you're right and simple does change more surfaces than precise.

Smallest actually still improves sticky corners over the old method -- it turns on fix #2 but leaves off fix #1 from my explanation page. Because it doesn't fix bug #1 you're still going to have sticky corners.

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'>
-cliptype legacy (Classic clipnodes, classic sticky corners) (no fixes, all like old)
-cliptype precise (Some new clipnodes, no sticky corners) (clipnodes could go up or down) (both fixes on walls and ceilings)
-cliptype simple (All new clipnodes, no sticky corners) (fewer clipnodes than precise) (both fixes everywhere)
-cliptype smallest (All new clipnodes, some sticky corners) (fewest clipnodes) (fix #2 everywhere, fix #1 turned off)
</td></tr></table><span class='postcolor'>

Ollj · February 2003

Corrected myself gut got quoted already, now its all clear...
ill compile my map with all 4 settings (wich is large and has MUCH places were you walk in the sky and keep stuck as skulk with classic CSG) to get a reference...

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'>
My Map has almost reached its clipnode_max and has some really complex flooring, lots of curved surfaces grossing "cave like diagonals". there are almost no 90° angles at the walls of my map

legacy:
clipnodes 30165/32767 241320/262136 (92.1%) (classic)
precise:
clipnodes 23143/32767 185144/262136 (70.6%) (some thin "bridge solids" can become "illusionary/noclip")
simple:
clipnodes 21968/32767 175744/262136 (67.0%) (exactly the same as above)
smallest:
clipnodes 24267/32767 194136/262136 (74.1%) (more clipnodes than precise/simple, less than legacy, classic feeling)
</td></tr></table><span class='postcolor'>

As far as I can see <b>"precise" is GREAT.
It kills ALL places were I got stuck as Skulk when I climbed along the walls.
NO MORE GETTING STUCK AS SKULK , no more getting shoot stuck at a corner or falling off the wall! Its all soo fluid.
Flay will need to reballance NS, because this gives Skulks such a big advantage!!!;)
I begin to hate the official maps for their skulk-stuck clipping corners compared to maps compiled with "precise"</b>

The bad thing:
I have some thin bridges and thin walls (like the way from Marine Spawn to Holoroom were you see the sky) and some theese thin Walls AND flooring become like noclip <img src='http://www.natural-selection.org/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>
An intelligent mapper can avoid such thin noclipped walls (they block wis but are not solid), but its a restriction <img src='http://www.natural-selection.org/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>

The confusing thing:
"smallest" gave me more clipnodes than "precise" and "simple".

tommyd · February 2003

great job cagey, keep up the good work!

Cagey · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Feb 21 2003, 12:26 PM)</td></tr><tr><td id='QUOTE'> The bad thing:
I have some thin bridges and thin walls (like the way from Marine Spawn to Holoroom were you see the sky) and some theese thin Walls AND flooring become like noclip <img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>
An intelligent mapper can avoid such thin noclipped walls (they block wis but are not solid), but its a restriction <img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'>

The confusing thing:
"smallest" gave me more clipnodes than "precise" and "simple".  </td></tr></table><span class='postcolor'> 
I've gotten a sample map from Ollj to try to diagnose where the problem is coming from -- I haven't had any problems with my test maps, but the map he sent me does reproduce the problem, so I'll update here once I've tracked down what's happening.

Green_Meat · February 2003

Have I mentioned that Your the Man!

I dont mean to kiss your ****, but I can't help it. I've been wondering for YEARS why 'somebody' didn't fix that (not even knowing if it WAS fixable). I cannot express my gratitude to guys like you who get elbow deep in code and work magic. The improvements you've made are truely impressive, and a wonderful service to us all. I'd say the entire HL community is in your debt, but that's just my opinion.

Speaking of the entire HL community, I think this might be an important break thru for HL Rally mappers. If I remember right, they had issues with their cars sticking on edges like skulks do. I can't be sure though, as this is second hand info that I recieved a while ago.

I'd say 'Keep up the good work!', but I couldn't in good concience ask you to do more than you've already done. Instead, I will simple say:

Thank you Cagey.

GSH

Cash_Car_Star · February 2003

I've always wondered if this could be fixed. Always mussed me up when I would try and make cliffs using triangular prisms. Mad props man.

Comprox · February 2003

The amazing work of maps and code for maps being posted recently is eve getting me excited, and my ns_halfass is looking promising to finish! <img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'>

chubbysteve · February 2003

Right. So this means that from a straight wall to a slope I shouldn't get caught on anything, and should just roll over the slope?

I must test it myself.

Ollj · February 2003

so true.
so great.
and it even makes clipnodes smaller.
Eclipse was downscaled 2 times because it reached max_map_clipnodes.

the error, I mentioned, seems to appear only if you have invalid solid brushes anywere in your map.

tommy14 · February 2003

Kudos to Cagey! <i>again!</i>

gaggle · February 2003

Oh.. My.. God!
Could this man <i>be</i> any more kickass?

And yes, that's the first and last time I do a Chandler impression.

BigD · February 2003

That was a fantastic explanation on how clip hulls work and all that! You're working some real magic here! This stuff is gonna make some real perty maps in the future!

KungFuSquirrel · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Feb 22 2003, 05:04 PM)</td></tr><tr><td id='QUOTE'> Eclipse was downscaled 2 times because it reached max_map_clipnodes. </td></tr></table><span class='postcolor'>
No.

No, no, no.

Did I mention no?

I never encountered problems with <b>any</b> limits during Eclipse construction. Clipnodes take up the largest chunk at something like 70.2% and have never gone any higher. I don't remember off-hand the plane count of Eclipse 1.0, but the newer 1.1 version is even lower (without the optimizing tool, which I have no use for at this point in time). The only issues were allocblock:full errors, which I now believe to be related to the overall volume of info_location entities (at least in regard to its common occurence in NS maps).

Cagey · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (KungFuSquirrel @ Feb 22 2003, 05:26 PM)</td></tr><tr><td id='QUOTE'> No.

No, no, no.

Did I mention no?  </td></tr></table><span class='postcolor'> 
I guess no means no? <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

The update was motivated by my desire to solve the sticking problems that were really prolific on my map. The clipnode drop that happens in some cases is a sort of bonus.

I'm still working with the map that Ollj sent me to find a way to accurately predict which illegal brush shapes will blow up the edge based beveling used by the simple and precise clip types (described in the article linked in the first post). If you stick with legal brushes (and don't have any vertex manipulated concave brushes, which WC will sometimes fail to report as illegal), you'll be fine.

Wolv · February 2003

<i>If you stick with legal brushes (and don't have any vertex manipulated concave brushes, which WC will sometimes fail to report as illegal), you'll be fine. </i>

If you've still got trouble with illegal brushes, open the exported .map file with <a href='http://dynamic.gamespy.com/~quark/' target='_blank'>QuArK</a>, do a check for problems and export again. Because QuArK uses the same method to describe brushes as the .map file does it is impossible to create illegal brushes.
If you're afraid that using QuArK will screw up your map, you can use it to determine where the illegal brushes are located and then delete them in WC.

chubbysteve · February 2003

Will this hlcsg exe work with merls 1.6.1 bulid of compile tools?

Yamazaki · February 2003

About time you did this! What took you so long? Geez! <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

At this rate, Half-Life will be tweaked into a premiere game that rivals Doom 3 before it's released... or something <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

By the way, about the max planes fix, maybe you should set the compiler limit to the max size of whatever data type is in use? I'm guessing it's an unsigned int.

Also, I'll take this opportunity to request another fix for the HL Mapping masses...

Proper HLRAD lighting on liquid surfaces!

Currently liquids (!textures) are rendered fullbright no matter what the lighting conditions are. I'm wondering if it's possible to force HLRAD to create lightmaps for non-transparent liquid surfaces, as this would fix the problem of seeing glow-in-the-dark water, especially if the same body of water is lit differently at various spots.

I used some trickery to fake properly-shaded water, but it had some visual flaws. I made an animating texture for the water, but the animations ran so fast that it looked like quivering jello. Also it required two entities per body of water, one of which had to be a func_water and that adds a fair bit of overhead due to the wave effect (Even if the waves are set to 0 height and the ent is made invisible).

Cagey · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (chubbysteve @ Feb 23 2003, 05:17 AM)</td></tr><tr><td id='QUOTE'> Will this hlcsg exe work with merls 1.6.1 bulid of compile tools?  </td></tr></table><span class='postcolor'> 
Yeah, unless you go over the old planes limit during the CSG phase, which would be pretty tough to do.

Merl hasn't gone over the new code yet, but he said he'd probably get a chance to on Monday. I'm hoping he'll integrate it for the next official release.

Cagey · February 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Yamazaki @ Feb 23 2003, 09:13 AM)</td></tr><tr><td id='QUOTE'> By the way, about the max planes fix, maybe you should set the compiler limit to the max size of whatever data type is in use? I'm guessing it's an unsigned int.  </td></tr></table><span class='postcolor'> 
There are three structs that use a planenum field in the HLSDK 2.3 version of the tool code-- dnode_t (int), dclipnode_t (int) and dface_t (short)... the change from version 1.3 to version 1.4 of opt_plns actually changed the dface_t field from short to unsigned short to allow planes over the old limit to be read properly--since the BSP file stores the number as 16 bit for faces, 64K is going to be the limit unless I store the data outside the bsp file or find a way to safely cull planes earlier in the tool path. Zoner's copy made the change to unsigned short in version 1.6 according to source comments.

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'>Also, I'll take this opportunity to request another fix for the HL Mapping masses...

Proper HLRAD lighting on liquid surfaces!</td></tr></table><span class='postcolor'>

I'll look into it -- the engine might not allow it since it has a unique step (texture deformation) for liquid textures which possibly denotes a slightly different code path in the renderer. I have one other current project, then I was planning on overhauling HLRAD to see where I could speed it up / lower memory usage... I'll explore liquid lighting while I'm looking for optimizations.

Asraniel · February 2003

*Asraniel makes a little shrine and prays every day thet XP-Cagey dont have to eat,drink and sleep so that he can continue to make such genious complier fixes/optimisations/improvements*

or in a short version:

YOUR ARE MY GOD!!!

Umbraed_Monkey · February 2003

I dont know much about this stuff, but, does this also solve the skulk-stuck-for-a-sec-in-unwelded-weldable-vents problem?

WolfWings · February 2003

No, because that is a client-side prediction error that Flayra would have to fix.

To prove it's a prediction error, cl_nopred 1
Suddenly, no more 'pause' at unwelded vents.

CrAcKbRoCk · February 2003

Wow, all I can say is...wow.
XP-Cagey, I truely hope you can continue to blow my brain straight up and outa my head, way to GO!! <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

*pop!*
*CrAcK's brain goes flying*
*CrAcK's brain says "wwweeee!"*

Asraniel · February 2003

*bump*

sticky this tread... it was on the second page....

watch_me_die · February 2003

Someone give this man a cookie =]

WolfWings · February 2003

Ollj · February 2003

Just found another small bug: when you use "Precise" -> on some (bigger) stairs as skulk you can see in the void when you look 45° down and stand close to the next step, but dont go up.

This just happens on solid stairs wich have big (and complex) steps.
A clip brush simply solves this.

Updated Hlcsg Fixes "sticky" Corners

Comments