Some Basic Help For Mappers And -chop

WolfWings

<div class="IPBDescription">...since it came up recently, some math.</div> This may sound minor... but what's the best setting for -chop? That depends on what you're trying to do. First off, if you're using opaque entities, realize that it's faster to compile a map the size of Nancy with -chop 32 and -nopaque, disabling opaque entities but quadrupling the resolution of your lighting, than it is to compile it with -chop 128, which reduces the lighting resolution to a quarter of it's existing size. The -chop value is actually how large each 16x16 section of lightmap is applied to. (Technically 15x15 due to technology decisions made in Half-Life, but the rough assumption is easier to calculate with, and simple to understand for this forum post.)

What does this mean for you, as a mapper?

A value of 64 is the default. It means that for every 16 pixels (4x4 box) in a texturemap, 1 pixel of lighting is calculated and applied.

For 'mouse scale maps' a value of 16 is actually feasable, but this is the only situation I know of where it is, as while it gives you identical resolution for your lighting as your texturing, it takes 16 times as much time, memory, and lightmap space to calculate and store.

A value of 32 is considered overly high quality by almost all involved. It means every 4 pixels (2x2 box) has lighting calculated and stored independantly. This means there is 4 times as many locations to calculate lighting for, which also means HLRad will take, on average, 4 times as much memory.

A value of 48 is one lighting calculation (and pixel in the lightmap) for every 9 texels (texture pixelx, 3x3 box) and will take just under double the memory, space, and time to compute.

Now, on the other side of the -chop scale... reducing your lighting quality for faster compiles, and a note. There's never any help gained from setting your -chop higher than your -subdivide value. A lightmap cannot cross a subdivision boundary.

As a comparison though, a value of 240, the default -subdivide value, will have 225 texels (15x15 box) and will take approximately 7% of the memory, space, and time to compute. You will also have no effective resolution at all, so any shadow edges except those that are axis-aligned will be effectively removed.

Scaling down to a 'reasonable' quality/speed/size tradeoff, if your map runs out of system, virtual, or lightmap memory at a -chop of 64, is a value of 96 or 80. At 96, you'll be assigning 36 texels (6x6 box) and will take roughly 45% as many resources. At 80, you're only assigning 25 texels (5x5 box) and consuming 64% of the resources.

Ideally, if you can, you may actually want to tune your -chop value to maximize your lightmap usage as much as possible without going over the limit. More is something you can always consider better in this case. :-)

If anyone has any questions, feel free to ask. I'll try to answer them, as will everyone else here I hope.

Reese

So basically within the bounds of 32 and our subdivide (240 by default) increasing the -chop will give faster compiles with lower quality but still present RAD lighting, which a lower value will make higher quality lighting than normal, but take longer and use more system resources. My question is exactly <i>how</i> the lighting is higher quality? does this setting change make the transition from light to shadow more subtle, because there are so many more surfaces to apply the light data to? Are there any downsides besides increased cpu resource usage and compile time?

WolfWings

Decreasing -chop will make the transitions <b>sharper</b> actually. Lower value = sharper, more well-defined shadows. This is far less apparent for shadows that are aligned to the underlying texture. I.E. If you cast a shadow with an edge perfectly aligned to 0, 45, 90, or 135 degrees, it will be MUCH sharper, especially at 0 or 90 degrees (aligned with the X, Y, or Z axis) than if it was at some in-between angle. Higher values of chop make these off-axis shadows <b><i>much</i></b> more noticable, but at a certain point, all the shadows blend into indescript blurs, so a very high -chop value can result in a very functional map, with very sharp shadows at some brush transitions, which can actually be exploited to good effect with trial and error.

If you want super-sharp shadows somewhere, say on the light cast by a pillar for instance, you can use hint brushes (or sometimes simply cut the normal brushwork) and if you're careful and don't mind experimenting with your compiles, you can get razor-sharp lighting. This is a more advanced technique that can result in some things looking out of place if over-used, but with careful use (and perhaps only partial chops and careful tuning of the -chop value) can be used to provide the illusion of shadows that sharpen as they get further away from, say, a column.

Also, there is a functional limit of 6MB of lightmaps in the HL1 engine according to recent tests that were run. This is also the default limit in XP-Cagey's p12 toolset for this reason. As an example, you're limited to 4MB of textures in NS maps, but you can re-use texturemaps across the level. Lightmaps are never (currently) reused, so if you make your -chop too low, you'll run out of lightmap space. I believe XP-Cagey has said that his new toolset will support merging duplicate lightmaps, which will reduce the lightmap space used in an identical way to how textures are re-used currently. This will likely double or triple the space available for lightmaps (judging from experience in Q3A, where this is already done with current tools), which would allow even maps close to the lightmap limit to reduce their -chop value almost in half, so long as they don't mind the increased compile times.

Then again, if you're currently compiling with opaque entities, the speedup from using XP-Cagey's tools alone will likely make the map compile faster with the reduced -chop value and perhaps even -extra (or it's equivilant in the new tools) still be faster than the brute-force lighting HLRad currently uses.

And yes, this information is all from publically-available posts and comments XP-Cagey has made, if you look enough. :-)