MAX_MAP_CLIPNODES Fixes? Created 18 years ago2005-12-30 21:33:36 UTC by Sandurr

Hello,

My maps big,
yes big.

Now, I wonder, how can I fix the error MAX_MAP_CLIPNODES?

I've added some CLIPNODES on skys and places that aren't really important (top sky, side roof buildings)

If I have this:
http://www.inztantfun.com/noclip.JPG

If I cover this up, Like this:
http://www.inztantfun.com/clip.JPG

Would this help (alot) ?
I really need to know this, cause this error is getting on my nerves =.=

Thanks alot!

No, clip brushes don't affect the engine rendering. They just block the player.

Quote from Tommy - http://www.slackiller.com/tommy14/errors.htm#clipnode

MAX_MAP_CLIPNODES

There isn't any way to add more nodes or clipnodes to the bsp's (its already maxed out). However, at least clipnodes can be reduced with a bit of work.

When the maps are compiled all the 3d 'space' a player can get to is broken up into convex regions just like brushes are required to be, alot of them are extremely small or too small for a player, and if you put a CLIP brush over them they don't become clipnodes at all (well really there are still a few intersecting the brush on its surfaces, but the brush can be excluding dozens or hundreds of them at a time).

If the world has had a 'box' placed around it to prevent leaks, its probably causing several thousand (if not 10000+) extraneous nodes and clipnodes to be caused, not only wasting resources but will cause vis to work a lot harder than it needs to. An example map is available, demonstrating how it is possible to reduce the clipnodes in a map. Without the clip brush in place, the map requires over a hundred more clipnodes to define the player-accessable space.
Merle's new compiler also trims some excess unneed clipnodes, which means a little more you can build. Get it.

I need a proper explanation because I really don't understand that one, what DO I DO to fix it =.=

I need that example fix aswell

Just read it all carefully.. It's all explained perfectly.

A clip brush is a block textured with the clip texture over all it's sides, it blocks players/monsters! I hope that will help you understand.

MAX_MAP_FACES MAX_MAP_CLIPNODES HL1 ENGINE

People, who don't understand that even the most advanced engine has limits, not to mention the HL engine. :

ok first I got MAX_MAP_CLIPNODES, after setting Clip Type in batch compiler to precise, I got max_map_faces, after making some roof texture scaled 5+ HLBSP CRASH =.=

Can you show us the map? You can upload it to the problems section. That'll give us a chance to look at it and give more detailed explanations.

Just a question about those wires bytheway, are they func_walls or normal brushes? You'd better make them func_walls or even better, func_illusionaries in this case, since these don't block the player. Entities in general are easier to handle for the vis process since they don't cause extra face and node splitting. As a rough thumbrule, make every small, detailed brush a func_wall, or if it's better that it doesn't block the player (small wires and stuff for example), then make them func_illusionary.

func_? => bigger r_speeds

i'll just make them func_illusionarys after all just to see

nothing =.=

USE THE EDIT BUTTON!

christ, people like you REALLY piss me off. Elon & Daubster are trying to HELP you so stop agrivating them. And don't expect us to solve all your problems when to be prefectly honest you're acting like a total ass.

func = LOWER r_speeds

entities are easier for VIS to handle, also RAD doesn't bother with them so you're map compiles faster. This probably won't fix your problem but its something to know.

As for your main problem, actually bother to READ what ZL posted. It's pretty clear to me.

func = higher r_speeds, I know it, you see funcs tru normall walls, the more you got the higher r_speeds you have

Depends on the situation. VISing is a pretty complicated business.

Ok, anyways, the problem is MAX_MAP_CLIPNODES, nothing works, -noclipeconomy doesnt , clipmode precise not, WHAT DOES? :S I really need help on this MAXNODE SIZE 6200 doesnt work....

maxnodesize says max is 8192 but it already stops at 6210 at mine, just doesn't move HULL

Command line: "C:Valve Hammer Editortoolshlbsp.exe"-maxnodesize 6200.0 -chart
-estimate -texdata 10500 -lightdata 6450 "C:Documents and SettingssandurDesk
topMapssin_citysin_city_cbeta47"

Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 10752000 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 6200 ] [ 1024 ] (Min 64) (Max 8192)

SolidBSP [hull 0] 500...1000...1500...2000...2500...3000...3500...4000...4500...
5000...5500...6000...6500...7000...7500...8000...8447 (10.98 seconds)
BSP generation successful, writing portal file 'C:Documents and Settingssandur
DesktopMapssin_citysin_city_cbeta47.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...
5000...5500...6000...6500...7000...7500...7779 (12.70 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...
5000...5500...6000...6277 (6.97 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...
5000...5500...6000...6500...7000...7500...8000...8482 (16.25 seconds)
Error: Exceeded MAX_MAP_CLIPNODES
Description: The map has a problem which must be fixed
Howto Fix: Check the file http://www.zhlt.info/common-mapping-problems.html for
a detailed explanation of this problem

Func_?=> LOWER R_speeds

And I'll tell you why! If a world brush touches another one vis wont render the face that you can't see, the problem is if the other world brush is bigger then the first one. The unrendered area is smaller then the whole face then to determine which area will be rendered vis splits the face to the unrendered part and many rendered ones, this adds many to the R_speeds sometimes.(they aren't only one face for Hl1 can't have convex faces) On the other hand vis ignores entities so it wont split any faces!

And what part of

USE THE EDIT BUTTON

did you find so hard to understand?

If you just uploaded the map so we can take a look, perhaps you could get a solution... this is going nowhere, since we don't know the exact situation and all.

It's just like entities and r_speeds: it depends on how you use them whether or not r_speeds (or rather, performance) inproves. You'll need solid walls to block line of sight, but some objects just don't block sight, which is especially true for small, detailed brushes.
Also, entities are rendered whenever their bounding box lies within the Potentially Visibility Set (type 'gl_wireframe 2' in the console to see what is rendered and you'll get an idea of what the PVS is at that moment). This means you'll have to mind the entities shape - putting every wire in the map into the same entity causes it to be rendered almost everywhere, while putting every wire into an entity of it's own doesn't cause this problem. You may hit an entity limit somewhere in that case, so you'll have to find a good balance between the two.

An added advantage of using entities for smaller objects is that not only face-splitting is avoided, but the VIS job also gets simpler, which means the VIS compile time will be lower and you're less likely to hit these kind of limits.

Then again, we can give you little help if we don't get a better view of the situation. What may help in one occassion, may not help at all in another.

Have you tried a batch compiler?

Would make little to no difference, Unbreakable. Except for some more resources it's absolutely no magical solution, that batch compiling stuff. (In fact, the compile process you launch from Hammer is quite batchy itself already ;)).

Basically the problem is that for every little angled face, you have a CLIPPING surface generated.

My first plan of attack when trying to eliminate MAX_MAP_CLIPNODES is to place a CLIPPING brush (a simple cubic brush with the CLIP texture on all faces) in any little spaces where the player cannot actually get to. For instance, if you have a couple of pipes running along a wall, or a fancy stairway with a space behind it which you can see but not reach, fill it with a CLIP brush.

Secondly, if you have any fancy-shaped walls, go through and fill them in with a single CLIPPING brush. For example, compare these two screenshots from Hammer, from my latest level in progress:

Unclipped:Clipped:Of course, CLIPPING blocks are not visible in the final compiled level.

I was going to give you a link to an article by xp-cagey about clipping hulls, and how they are generated, and what they do -- but the site is down. This article seems to briefly cover the basics of clipping hulls, and might be worth a read. You need to have a clear picture of exactly how/why clipping hulls are being used, so that you can decide whether or not to place a hull in a particular spot.

As you can see from the screenshots, each of the CLIPPING blocks I've placed only saves 2 CLIP faces (there were three, there's now only one.) I had quite a few such walls, however, so it seemed a reasonable place to apply the method - and as it happened, it got my level compilation going again. The biggest problem with using this method is that - with the version of compile tools I'm using, anyway -- it doesn't tell you how many clip nodes you've actually got, it only tells you you've got too many. So proceeding like this is very much a blind effort; you have never got any idea how close you are to solving the problem...

Hope that helps...

An excellent summary.

I think you can probably use -verbose or something to show detailed compile resource usage stuff. Have a look at zhlt.info.

I think you can probably use -verbose or something to show detailed compile resource usage stuff. Have a look at zhlt.info.

Thanks; I'll give that a try. (I'm still working on the level in question, and it's currently run into one of these limits again, so now would be a perfect time to test that...)

Results: For my current error, MAX_MAP_FACES, it doesn't give me conclusive results. There is a lot of output which looks like this:

-- MergeAll --
226 mergefaces
--- SolidBSP ---
-- MergeAll --
246 mergefaces
--- SolidBSP ---
-- MergeAll --
236 mergefaces
--- SolidBSP ---
-- MergeAll --
92 mergefaces
--- SolidBSP ---
-- tjunc --
131 world edges 291 edge points
14 edges added by tjunctions
0 faces added by tjunctions

So perhaps if I went through and added all the "mergefaces" totals it might tell me something interesting -- but I suspect that the code itself simply stops processing as soon as it hits (or exceeds) the limit, and hence it doesn't actually know what the total number of faces (or whatever) actually is. Maybe some day when I've got time I'll actually look through the code to confirm that... shrug

Hi fellas,
Im new here but have spent quite alot of time reading the posts. I am having the ERROR:MAX_MAP_CLIPNODES preoblem.

Im sure your all tired of this subject but I really beleive I will get some help here.

OKAY, I know what I can doto fix this error, I need to change my "hlcsg" compiling setting to -cliptype smallest instead of the default "legacy". I JUST DONT KNOW HOW THIS IS DONE. I thought if I type this little command into my (ADDITIONAL GAME PARAMETERS) box using NORMAL COMPILE MODE, it would change the setting, but unfortunatly it doesnt, can anyone here give me a clue?

This is what my normal compile thingy looks like.

Im about to pull my hair,hold my breath and stomp my feet in frustration


anyhelp will do!
Fuzzy

Press the Expert button, and you'll have a more complex looking box. Type in your parameter like this:

Lulz, shameless plug for my mod. Still, I hope that helps. And, uh, try not to hijack any threads in they future, eh?

it doesn't tell you how many clip nodes you've actually got, it only tells you you've got too many.

Running the -chart parameter for any of the compile stages will tell you what resources you've used and what you have left, including clipnodes for the BSP stage:Nice to see you btw DarkPhoenix68!!!!

@Sandurr: I've not had a problem with clipnodes yet... thankfully I concurr with Captain P though, upload the map to the Problem Section.

And don't be so quick to condemn the HL1 engine. Most of us here have been using it for a long time to map, and I would say very few of us--if any--have used it to it's full potential. It has limits sure, but is still quite powerful considering how old it is.