Hl Limits : Maxplanes And Maxclipnodes
mateo
Join Date: 2003-04-08 Member: 15320Members, Constellation
Join Date: 2003-04-08 Member: 15320Members, Constellation
Hello,
I'd like to know what are really the HL limits.
The map my team is making is using a lot of polygons (of course wpolys are low, but the map is quite big).
So, with just a part of the map (around 1/3) we are using 50 % of the maxplanes and 50% of the maxclipnodes.
I've heard of the XP Cagey tools, but will they really help us in this case. Will the server lag if there are a lot of polygons in the map ?
I just need some help of persons who understand how HL works in this case. (Maybe coders)
Thanks <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I'd like to know what are really the HL limits.
The map my team is making is using a lot of polygons (of course wpolys are low, but the map is quite big).
So, with just a part of the map (around 1/3) we are using 50 % of the maxplanes and 50% of the maxclipnodes.
I've heard of the XP Cagey tools, but will they really help us in this case. Will the server lag if there are a lot of polygons in the map ?
I just need some help of persons who understand how HL works in this case. (Maybe coders)
Thanks <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Comments
XP`s compilers have way higher limits and are recomendet for NL mapping (and are faster).
They set the plane limit to "almost infinite", increase clipnode limit a bit and make clipnodes way better (no skulk gets stuck on a wall-border anymore.
The r_speed tells you the render speed of a client (depending on visible polygons) wich can only cause lag on a non dedicated server. Mapping guidelines set the limits at 700 and 1000 for comm view.
When you have a large map your biggest problem is the leaf limit. Leafes are invisible blocks that fill all the visible volume of your map.
Another problem is that you can place more stuff in a big map wich can exhaust the server more.
I talk a little bit about what clipping is from an engine perspective and what my tools actually are doing <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>here</a>.
excellent laymans description of clip BRUSHES <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. thanks for pointing it out.
I talk a little bit about what clipping is from an engine perspective and what my tools actually are doing <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>here</a>. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
excellent technical description of clip BRUSHES <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> hehe
got the simple and the technical, best of both worlds...
now after reading both links i have a question.
do *I* have to worry about my creating my own clip brushes on walls, objects, etc, since it sounds like it is handled when compiling the map (I'm already using your tools XP-Cagey).
Is there a situation when the clipping that is done when compiling is not enough?
Thanks.
I talk a little bit about what clipping is from an engine perspective and what my tools actually are doing <a href='http://xp-cagey.com/articles/clip_hull' target='_blank'>here</a>. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
excellent technical description of clip BRUSHES <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> hehe
got the simple and the technical, best of both worlds...
now after reading both links i have a question.
do *I* have to worry about my creating my own clip brushes on walls, objects, etc, since it sounds like it is handled when compiling the map (I'm already using your tools XP-Cagey).
Is there a situation when the clipping that is done when compiling is not enough?
Thanks. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
<i>EDIT: No, you should be fine 99% of the time without worrying about clip brushes <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--></i>
The difference between a clip brush and a normal brush is what happens with the vis hull -- every normal brush makes a clip brush copy of itself for the other three hulls (not entirely accurate, but close enough). In recent copies of the tools, sky brushes also generate clip information unless you tell the compiler otherwise--the other link's information might predate that change.
With the updated clipping code, the automatically generated clipping ought to be enough for most levels -- if there is a really complex object like the desk lamp in the other tutorial, using a clip brush will help your final clipnode count, but it isn't as critical as it used to be.
I use clip brushes for cases where I want to smooth out corners (like the desk lamp example with angled sides in that other link) for most of my mapping. Skulks can't walk on clip brushes, though, so I don't use them as much in NS mapping.
It's hardcoded into the .bsp format as a 16 bit unsigned integer (64K - 1 = 65535 max clipnodes). Valve would have to change the file format (including the Half-Life code that reads the format) before the number could be raised.
There might be some more I can do to lower the clipnode count for existing geometry -- I have one idea that would at worst leave the map unchanged but could potentially lower the count (like opt_plns lowering the planes count, but not as significant a change).