Orange Light = Green Walls Revisited

As originally posted by GB last year: http://kneedeepinthedoomed.wordpress.com/2010/11/07/orange-light-green-walls-far-out-experiences-with-colored-light/

Further work and experimentation has positively identified the criminal in this case as clamping.

Now, encoding the lightmap as a HDR texture format and decoding it in your fragment shader goes a long way to resolve the effects of this engine-side - lights that get additively combined no longer have an upper limit and Mr Green is gone. Precision does fall off if you get really silly, but by then we're talking about colossal white glares on the wall anyway. The common case starts off the same as regular GLQuake's downshift by 7, with graceful linear falloff from there.

There's one other place that light gets clamped, and that's in the lighting tool. If a light has been clamped in the lighting tool then nothing engine-side can fix that - once you clamp a value to 255 you have no way of finding out if the original value was 256, 384, or 1,000,000,000.

This plays into the "LIT2" format I mentioned previously. No final decision has been made as to whether or not I'll even do a "LIT2" format, I haven't even discussed this with the RMQ guys yet, I'm just throwing this idea out publicly.

The idea is that "LIT2" won't clamp. There are two ways to go about this - use a higher-capacity format or encode the result to allow the original to be reconstructed.

If using a higher capacity format the obvious choice would be shorts. You could even use signed shorts and have negative light contributions from combined lightstyles (you'd need to watch your lower bound when building the lightmap in-engine though). The LIT file size would double.

Encoding involves another HDR format in the LIT file. It would go from 3 channel to 4 channel, with the 4th being used to decode the first 3 (the LIT file size increases by one third). That could be done at load time or at run time (load time is less memory efficient but faster, run time the other way around). There would again be some minor precision loss, but things can be done in the light tool to moderate this (using floating point instead of integer math, rounding to nearest, etc) that can't be done engine-side owing to perf loss pile-up.

An interesting side-effect would be that the way you light maps might need to change a little. Previously you could put a hugely bright light in the center of a room, confident that it would clamp, and light the room relatively evenly. Take away the effects of clamping and that changes - surfaces nearer the light would now get the huge brightness. A proper decoupling of light intensity from light radius may be required.

Whatever, this is still entirely in the realms of speculation and might not even happen at all.