Lightmaps - A Conclusion

The culmination of my recent work on the lightmapping code has been reached, and it goes something like this.

The experimental HDR texture formats are gone. Too much messing, performance issues and quality tradeoffs involved in trying to get a better range out of 8/8/8/8 textures.

64-bit lightmaps are back in DirectQ. These are now the default mode and used if available. There is some speed loss incurred from using them, but on balance having an effectively unbounded range more than compensates. It also gives me some motivation to try claw back the performance from elsewhere.

If 64-bit textures are not available on your hardware DirectQ will look for 10/10/10/2 texture support. This 32-bit mode is very widely supported, has roundabout got performance parity with standard textures, and gives 2 extra bits of precision to play with per-component (the alpha component is not used). What this means is that it can achieve 4x the dynamic range of standard GLQuake lighting without compromise (in practice there are a few places even in ID1 maps that exceed even this range, so we clamp if required).

If this format is not available (unlikely) the final fallback is to standard 8/8/8/8 textures (D3D only has one 8/8/8 format available and hardware support for it is poor so I don't even bother checking).

DirectQ is now overbrights only, and on all the time. I had thought about doing this a few times in the past, and the new texture formats made my mind up for me. The rationale for this is that software Quake was also overbrights-only (as a quick check of the colormap.lmp file will confirm), Quake II had overbrights, Q3A had overbrights. Why is GLQuake so lonely in the middle without overbrights? I'm contending here that overbrights are ID's intended look for all of these engines, and that GLQuake was nothing more than an experimental stepping-stone to Quake II. On account of that, any oddities in it's behaviour - especially when they differ from software Quake - should be discarded.

Would someone say that heaving and buckling skies are part of Quake's intended look? What about tearing/shearing water surfaces? Or huge polygon cracks you could sail a Star Destroyer through when underwater? These are all things that were abandoned when ID finished GLQuake's development, and my argument is that lack of overbrights belong in that list too.

Some might say that if another few revisions of GLQuake had happened then these would all have been fixed. Others might say that these revisions did happen - it was called Quake II.

I'm retaining the ability to switch fullbrights off as there are too many released maps where the texture artist has screwed up. Yeah, I know that there are also places where the same could be said of overbrights, but thats something I'm going to take a stand on now.

Moving on, the ability to switch coloured light on or off has been restored. The old r_coloredlight cvar which has always been hanging around the engine now works again.

RMQ is - naturally - going to pick up on some of this stuff. I don't think I'll go with the 64-bit lightmap support (glTexSubImage2D is just too slow compared to D3D's LockRect/UnlockRect/AddDirtyRect stuff) but I will be implementing the 10/10/10/2 texture format, pending confirmation of some hardware support. I'll probably also leave the non-overbright mode available there.