Ns_olympus(mons)
Loodich
Join Date: 2003-07-16 Member: 18201Members
<div class="IPBDescription">teh crap</div> ive been working on this map for a while, but i ran into a MAP_MAX_CLIPNODES or some crap
<a href='http://www.guns4back2school.com/loodich/ns_olympus.htm' target='_blank'>http://www.guns4back2school.com/loodich/ns_olympus.htm</a>
if anyone can tell me how the hell i can fix the max clipnodes it would be greatly appreciated
<a href='http://www.guns4back2school.com/loodich/ns_olympus.htm' target='_blank'>http://www.guns4back2school.com/loodich/ns_olympus.htm</a>
if anyone can tell me how the hell i can fix the max clipnodes it would be greatly appreciated
Comments
To reduce clipnodes, you can delete small details, make them into non-clipping entities (like func_illusionary), or put a clip brush over them. I think that the rocky outcroppings in your map are creating a lot of clipnodes. Also, those steps and circular braces that go all the way around the hallway must be creating a bunch of clipnodes.
you can decrease detail in the volume, or just make the volume smaller or use XP-Cageys tools with "-cliptype precise" or "-cliptype smallest" in BSP
-cliptype precise can increase or decrease clipnodes depending on the map. you should always use precise when making your map unless you need the extra -cliptype smallest will provide.
but, all i gotta do is pretty much put clip brushes around big things? like the tanks in pic 2, surround em w/ a clip? or make them a func_illusionary then a clip?
Step 2: Are you familiar with adding parameters to the compile tools, like -full to vis? If not you should be. You can find tutorials for compile parameters on VERC that would do a better job explaining it (assuming you're using hammer) than I would. Suffice to say you should always have -full vis and -extra rad on a final build. One thing you won't find in a tutorial is information on -cliptype, because that's a new one, so I'll explain it in a bit more detail. The -cliptype changes are modifications to the Expandbrush function in hlcsg that forms the clipping planes. It's simply a parameter that goes on hlcsg.exe. That are 5 settings it has but you really only need to be familiar with 2 (that others are for backwards compatability, by default it uses the old way). '-cliptype precise' will make the clipnodes the best way possible, preventing sticky corners. This may have more or less clipnodes the the old way, so try it out. If possible this should always be used. If you have hit the clipnode limit and absolutly need more then use '-cliptype smallest'. This will try to use the fewest clipnodes possible, better than the old way but not as good as precise. There are no guarantees on how much this will reduce you clipnodes though, if you're significantly over the limit it probably won't be enough. (I haven't actually played around with that particular setting to qive you an idea of how much it can reduce clipnodes.)
Step 3: Now that we past everything you can do at the compile stage, we need to go back a bit more to get to what really matters, How the map is made. First let me explain basically what a clipnode is. Clipnodes define the area that players can move around in. The more complex this volume is, the mode clipnodes are required to define it. Fairly straight-forward. (Anytime someone says 'clipbrush' they are refering to a worldbrush textured entirely with 'CLIP'. Clipbrushes are completely invisble in-game) Now, here's how you reduce youre clipnodes. Go through your level and look for details that are not important to how players move about. The example I gave, the stairs, look nice, but are esentially just for moving up right? So make a clipbrush that is a simple ramp, that just barely covers the stairs. Make sure it matches the general shape so you don't confuse players, just have a ramp instead of steps. So what does this accomplish? Well, in-game your stairs will look exactly the same, however, the area the players can move around in, defined by the invisible clipnodes, will be a smooth ramp instead of the jaggy stairs, and will require fewer clipnodes to define. Any place a player can't get to, or isn't supposed to get to, can be filled in with clipnodes. Round pipes can be covered with square clipbrushes. And don't forget about the readyroom, which also counts for clipnodes. Any details at all in there should be covered with clip brushes to bring the count down.
That's about it. If you need more help with the compiling I can try to help you, though I use Quark and it's simpler to setup than Hammer, So I couldn't tell you how to add parameters in Hammer exactly, I could point you to some tutorials on that though. If you need more help on the use of clipbrushes I could draw you some pictures to help explain it better.
thnx for not flaming me for not knowing this stuff and helping me out, i appreciate it a bunch
im clipping up every little thing right now, and a buddy of mine told me how to compile using .bat files and whatnot, so im trying that out and soon ill have a chart of my clipnode ammount
well hey i got it
clipnodes 28593/32767 228744/262136 (87.3%)
w/ a few clip brushes i guess i lowered it a lot
but theres a leak in the map too somewhere, i swear i got all those out oh well,
There is one other thing I didn't mention. That Leak could be the main reason you hit the limit of clipnodes in the first place. If you don't have a leak, then it will only make clipnodes for the inside of your level, because it assumes that's the only place that the player can get to. However, if you have a leak it can't determine where the inside and outside are, so it makes the clipnodes for the outside of your level too. This could even double the number of clipnodes in your map, though often it's not quite that drastic as much of the detail in your level would be on the inside. After you fix that leak, I would suspect clipnodes won't be a problem at all.
Universal rule : ALWAYS fix leaks as soon as they appear. Leaks can potientially cause many more errors.
(One thing I like about Quark - If the compile tools report a leak, Quark interrupts the compile sequence and loads the point file automatically, so you can't overlook it)
15268 faces
Create Patches : 79357 base patches
0 opaque faces
1046889 square feet [150752128.00 square inches]
Error: Exceeded MAX_PATCHES
Description: The map has a problem which must be fixed
Howto Fix: Check the file ZHLTProblems.html for a detailed explanation of this problem
----- END hlrad -----
is what it said in the logs...so i guess i gotta figure a way outta this too
[EDIT]
i guess i have to put a "-chop 96" to get more lightmaps or something?
One, you can increase your -chop and -texchop parameters. This will make the patches largers, so a large wall will have fewer patchs. -chop is 64 by default and -texchop is 32. There are 2 problems with this however. Small details that are already smaller than 64 will still be 1 patch no matter how high you set -chop, so increasing it may not affect your number of patches very much. Also, because is will be calculating the light for fewer patches it will naturally be less accurate. This will cause shadows to look more zaggy or stair-step like. (Conversely, you can reduce -chop and -texchop to make shadows look better)
Option Two is to increase the maximum limit of patches you can compile. Either the setting -sparse or -nomatrix will let you have up to 4 times the normal limit of patches. -nomatrix is generally slower than sparse, but requires less memory space to compile. This is probably the better option. There is a drawback. Naturally, doing more calculations for all those patches will require more time to compile and will result in a larger bsp file in the end.