Software vs GLQuake: Fullbrights
This is another part of an (hopefully) ongoing series of posts showing some differences between the original software rendered Quake (quake.exe, winquake.exe and derivates) and hardware-accelerated GLQuake (glquake.exe and derivates).
Fullbrights are parts of textures (that includes model skins) that are always displayed in full brightness regardless of the surrounding lighting situation. There are also engines that support making whole models fullbright (for example for better visibility in competitive dueling). Those are usually called “fullbright skins”. That’s not what this is about, it is about the parts of textures that should always be brightly lit.
Notable examples in stock Quake would be the slipgate teleporter sockets and of course all the blinking red buttons. Many light textures also have fullbright parts in them but those are not as noticeable as they usually have an actual light source nearby (normally textures do not emit light in Quake but mappers have to place light “points” into the levels).
Fullbrights were part of Quake, good modern engines show them. GLQuake does not. Let’s take a look, left is what GLQuake shows, right is what an engine with fullbright support shows:
Let’s look at the technical background. Quake uses a palette file to assign colors to numeric values referenced in the texture files. The last 32 colors (two rows) in that palette are “fullbright”. The upper 16 ones are obviously used for fire effects so let’s ignore those. The lower (bottom) 16 are “the fullbrights”. By the way if you ever had really funky colors in Quake while playing some mod, chances are that there was a palette mismatch.
So far so good, but why does GLQuake not display fullbrights? The answer lies in the colormap file. “The colormap is a table used for lighting in software Quake engines. It contains a column of 64 values per each palette color. Each value is an index into the palette representing as closely as possible the original color brightened or darkened: shade 0 is double bright, shade 32 is the original color, and shade 63 is black.” The shades go top to bottom. If you remember the previous article about Overbright Lighting this might sound familiar. The shades 0-31 are where the overbrightness comes from.
Now if you look at the right side of the colormap you will notice those 32 fullbright colors again. This time as solid unshaded bars unlike the other colors in this image. The right-most ones are the fullbrights again. And since software Quake takes the color values from there it will display them always like that. Easy!
Well, as you might have guess now GLQuake does lighting completely different and does not use the colormap. Instead it treats all colors equal. Engine coders have to explicitly hard-code the fullbrights into their engines if they strive to make Quake look good.
This occasionally leads to ugly texturing disasters when mappers use bad tools to make their textures and test with stock GLQuake. Then sometimes fullbright pixels sneak in. A recent example being toa.zip – Temple Of Anubis: Judgement Of The Dead and an older much worse example alk15.zip – Brumal Quest.
Thankfully most good 3d-accelerated engines do support fullbrights. aguirRe’s glquakes being the notable exception at the time of writing.
References used:
Quake Wiki on Quake_palette#Colormap
Metlslime’s Quake Texture FAQ
and czg’s wisdom
Easily install and launch Quake maps with the cross-platform
21.11.2009 23:51
Thanks for this one, it’s very important. Getting overbrights wrong is at worst merely unpleasant, getting fullbrights wrong can completely destroy the hard work of the mapper and texture artist in creating an atmosphere.
It needs to be realised beyond doubt that both are deliberate intended features of the Quake engine, and making the point about the colormap reinforces this. It is after all trivially easy to generate a colormap that has neither.
23.11.2009 19:23
Of course by now, this is all usually handled by use of a shader system rather than relying on a pallette to provide fullbright colors on map textures.
09.12.2009 17:18
We need more articles like this. Maybe we can place a bounty on these kinds of articles? They’re very useful to new engine programmers; such as myself, in that they provide an in depth look at how things work in Quake without the reader having to dive straight into source code.
Hell, if Spirit can’t place a bounty on articles like this, I would be willing to negotiate with someone a price so that they could provide us with them, and maybe some more detail on what source files implement what is being described.
08.09.2010 18:53
[...] you're converting textures, make sure that you have a good read of this before releasing anything: Software vs GLQuake: Fullbrights (Although I assume that Baker's tool handles the necessary palette mangling automatically). [...]