Max Subdivide Size

taleden

<div class="IPBDescription">240 or 512?</div> According to everything I've ever read before, the maximum subdivide size (the biggest face BSP allows before splitting it) is 240 units, but looking through my log just now I noticed this:

subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)

Does this mean I can jack the subdivide up to 512 and save myself some wpolies?

Soylent_green

Yepp at the risk of horrible bugs, and when I say risk I mean there's just about 100% certainty that you will get horrible lighting bugs such as RAD making everything fullbright for no apparent reason even if you just up it to 256.

Mido

When RAD makes everything bright, that normally means a bug, a leak, or a texture issue...

Zazi

It's not so much as lighting, as it is just compiling at all. If you can get it to compile at even 256, great. The main reason why you cant is 'cause when you get higher than 240, textures at small scales will start to throw errors of sorts when you compile... If that makes sense at all... it probably doesnt. At any rate, download hlfix, and it'll help you compile with -subdivide 256 at least, although you can expect some errors.

taleden

Is it a compile tools issue, or an engine issue? If it's just the tools that can't handle bigger subdivide sizes, maybe Cagey can work some magic? But I would be surprised, it seems like the sort of thing that would require modifications to the game engine.. but if that's the case, it makes me wonder why BSP has that line about max 512, unless it's just a typo.

Soylent_green

<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> When RAD makes everything bright, that normally means a bug, a leak, or a texture issue...
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->

No in this case RAD runs(or in the case of merls tools which I tested with, cagey could have pulled some stunts but I doubt it.), takes a long time and everything comes out looking fullbright, pitch black or some other weirdness if it even manages to compile...

You can experiment with subdivide size with the -subdivide # option for HLBSP(I'm quite certain it's for BSP).

Thaldarin

<!--QuoteBegin-Soylent green+Apr 27 2004, 04:12 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Soylent green @ Apr 27 2004, 04:12 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> You can experiment with subdivide size with the -subdivide # option for HLBSP(I'm quite certain it's for BSP). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
It is for BSP.

prsearle

The problem with RAD is because of the way Half-Life handles lightmaps. The maximum size of a lightmap is 16x16 (this is a hardcoded limit in the engine). The engine calculates the size to use for each face using that face's size ('extents') and it's texture scale. This is why scaling up textures can reduce lightdata/make shadows blockier. Obviously, the compile tools have to use the same method of calculating lightmap sizes. Faces whose extents are greater than 240x240 will will cause RAD/the engine to try to assign a lightmap size greater than 16x16. Of course, the texture scale is factored in, so this is why faces with small scales are the first to cause problems.

taleden

Isn't there a -notexscale switch which causes RAD to calculate patch sizes independently of texture scale? And if so, doesn't that imply that patch size and subdivide size can be made to be independent? Maybe there is some way to use that to achieve higher subdivide sizes?

prsearle

Patch size and lightmap size are different things. Patches are small faces used to calculate the radiosity. Once the final lighting values for each patch are calculated, they're mapped back onto the 16x16 lightmaps.