Arg! Will The Pain Never End?
Ben128
Join Date: 2002-06-21 Member: 808Members, Constellation
Join Date: 2002-06-21 Member: 808Members, Constellation
<div class="IPBDescription">A little help please..</div> Ok.......ok....Breath ben...breath. Mapping is rather fustrating at times I must agree with many of you. I finally got all my textures that I wanted and got it to be well under the 4mb limit. Now I am at another impass. I tried to load and what to my wondering eyes did appear but a
ERROR: MAX_PATCHES . I know that scalling the textures helps, but am i just using to much texture or what? ANY advice would be great. I know my map is not big enough to be causing this either. its a good size.....but dang...
I just want this thing to work for me. I have scraped it 7...yes 7 times so far at various intervals. I knew this was going to be a learning expierence(i am new to mapping), but wow.
You can check out my work at <a href='http://www.sonsofmetal.org/images/map/' target='_blank'>http://www.sonsofmetal.org/images/map/</a>
ERROR: MAX_PATCHES . I know that scalling the textures helps, but am i just using to much texture or what? ANY advice would be great. I know my map is not big enough to be causing this either. its a good size.....but dang...
I just want this thing to work for me. I have scraped it 7...yes 7 times so far at various intervals. I knew this was going to be a learning expierence(i am new to mapping), but wow.
You can check out my work at <a href='http://www.sonsofmetal.org/images/map/' target='_blank'>http://www.sonsofmetal.org/images/map/</a>
Comments
simplest solutions:
use -chop with a squared number larger than 64 (default) "-chop 128" "-chop 256" -> more blocky light from light point entities
use -texchop with a squared number larger than 32 (default) -> more blocky light from texture lights.
Do NOT use -notecscale if most of your textures are stretched more than "x1".
Stretch your textures more. Using 128*128 textures streched by x2 instead of an unstretched 256*256 texture (of course this just makes sense without -notexscale).
Use -notexscale just when almost all of your textures are stretched less than "x1" (having lots of understreched textures is always a bad for RAD.)
Use "-bounce" with a small number (2-4 has best performance / 8 makes RAD cause ages uses lots of patches but look "realistic") (this determines the number of light reflections on surfaces) sometimes your light just bounces away too far reaching much more faces -> loss in realism.
Use "-dscale" and "-choring" (seach tutorials for that, it just makes your map "eating light" like in a black dust)
Use less lights of different kinds (color, brightness, custom appearance), make them all simular to each other.
Use less dynamic lights (its always a good choice, but does not help max_patches much).
Use less lights that reach many areas at once (less lights in short vents (ask the creator of ns_eclipse about that).
Do not mix much texture lights with much point entity lights in one big room.
Eventually use some solid Vis-blockers (they make the hull surface larger but can make some spots no longer reaching places far away)
use -chop with a squared number larger than 64 (default) "-chop 128" "-chop 256" -> more blocky light from light point entities
use -texchop with a squared number larger than 32 (default) -> more blocky light from texture lights.
Do NOT use -notecscale if most of your textures are stretched more than "x1".
Stretch your textures more. Using 128*128 textures streched by x2 instead of an unstretched 256*256 texture (of course this just makes sense without -notexscale).
Use -notexscale just when almost all of your textures are stretched less than "x1" (having lots of understreched textures is always a bad for RAD.)
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Any of the above will reduce your patches.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Use "-bounce" with a small number (2-4 has best performance / 8 makes RAD cause ages uses lots of patches but look "realistic") (this determines the number of light reflections on surfaces) sometimes your light just bounces away too far reaching much more faces -> loss in realism.
Use "-dscale" and "-choring" (seach tutorials for that, it just makes your map "eating light" like in a black dust)
Use less lights of different kinds (color, brightness, custom appearance), make them all simular to each other.
Use less dynamic lights (its always a good choice, but does not help max_patches much).
Use less lights that reach many areas at once (less lights in short vents (ask the creator of ns_eclipse about that).
Do not mix much texture lights with much point entity lights in one big room.
Eventually use some solid Vis-blockers (they make the hull surface larger but can make some spots no longer reaching places far away)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
These methods won't reduce the number of patches -- they will reduce the overall amount of light data, but the patches (locations for measuring light data and displaying a preset amount light in the game) are created before light entities are examined by HLRAD, so varying light entities (including tex lights) won't affect the final patches for a map.
Yes, using -sparse raises the theoretical limit of 65535 patches by compressing the vismatrix, but doesn't garuntee that you won't hit the patch limit.
From the source:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->#define MAX_PATCHES (65535*4)
#define MAX_VISMATRIX_PATCHES 65535
#define MAX_SPARSE_VISMATRIX_PATCHES MAX_PATCHES<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If you use sparse, you have 4 times the amount to work with (~256K patches instead of ~64K).
What I dont get is why it did not just give this error to me before I got so far. I layed the entire level out first and made all the basic archetexture. I had everything textured with a cement floor texture just to have it. After i built the entire level I started to add texture and lights.
In basic terms, by adding these lights I created more patches? Or was it new textures?
It ran until I recently finished my last two rooms. Both of those rooms have alot of dim lights in them also. Could that be causeing it.
As for the whole -sparse thing, could that have any negative effects on my map?
Every website I have been to explains some very general details about patches. But is there any more detailed reference on them?
I assume your generic concrete texture was always scaled at 1.00*1.00. Patches do however normally depend on the texture scaling - a wall with 0.5*0.5-scaling of a texture will always be divided in more patches than the same wall with the same texture scaled to 1.00*1.00. Likewise, would that wall be covered by a 2.00*2.00 scaling of the texture, it'd even produce less patches.
This whole thing can however be switched off by -notexscale, which is why I'm using it all the time.
I also read about the "null" texture...does that help on brushes that are not seen also?
Adding lights wouldn't affect patches, but changing textures might if you used a different scale on the new textures.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It ran until I recently finished my last two rooms. Both of those rooms have alot of dim lights in them also. Could that be causeing it.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If you added more surface area (brush faces * area of each face) to your overall map, it could have potentially sent you over the limit.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->As for the whole -sparse thing, could that have any negative effects on my map?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It shouldn't... by having more patches, you increase the amount of memory used by light data, but as long as you're under 4MB (or 6 using my latest version of the tools) you'll be OK.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Every website I have been to explains some very general details about patches. But is there any more detailed reference on them?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Unfortunately, I don't know of any detailed patch sites offhand.
A patch is a subsection of a brush face that has a uniform lighting value assigned to it by the RAD process. If you've ever seen "blocky" lighting from a spotlight in a map, each block is a single patch (see attached image).
Sometimes the compiler does not boolean-split intersecting texture faces correctly.
Then you calculate light patches for parts of faces of your map that you wil never see ingame (maybe some in comm mode).
To avoid this make sure that you see all borders of every visible face = no intersections of faces.