Saturday, November 7, 2009

Fun with Lighting

The differences between lighting in Software Quake versus GLQuake are well known, but for anyone who isn't aware of them a good summary may be found here.

One of the things that's not so well understood however is that Software Quake's lighting, as well as being overbrighted, is also non-linear. We're going to need to dive behind the scenes a little for the full explanation, so take a deep breath.

In summary, Software Quake uses a lookup table to determine the final colour of a pixel. This table is called "colormap.lmp", is contained in your pak0.pak file, and consists of 64 rows (each representing a different level of lighting intensity) and 256 columns (each representing a palette index). The result of a lookup is a final palette index which is then used for the final colour.

GLQuake just does a straight modulation of texture colour multiplied by light intensity, with the light intensity being in a range from 0 to 255. However, in software Quake the brightness scale ramps slightly differently, and rather than each of the 64 levels being equal in brightness it's more of a curve, with brightness accelerating slightly up to medium/high levels, then slowing down towards the end. The chart below illustrates the approximate difference.



This is one reason why Software Quake can look a lot more vibrant and alive than GLQuake (there are others). In order to achieve this in DirectQ I've added another step to video startup where it will read the colormap and derive the lighting curve from it. In practice it's not 100% correct as each entry in the Quake palette has it's own individual lighting curve, but it is an average of the curves across the entire palette, excluding fullbright entries.

Another thing that's recently come in is slightly corrected texture colours. I love a bit of wbrick1_5 (the brick texture in most medieval maps) but in GLQuake it just looks very green, whereas if you export and view the original texture you'll find that it's really quite brown. This has now been corrected.

2 comments:

Coranth said...

Wow... at the rate you're going, this is going to be a HUGE release when it's done! I'm eagerly waiting for more news and tech-data.

=peg= said...

Are you sure you are not confusing wbrick1_5 with wswamp2_2? (see the first image of this slideshow)

As you can see from the 3rd image in the slideshow, wbrick1_5 looks perfectly brown (for me at least) except when viewed from a very shallow angle, as seen on the slope, but i guess that's all down to the level of anisotropic filtering..

The 2nd image in the slideshow shows the wswamp2_2 texture..

(screenshots taken with DirectQ 1.7.3)