Lighting:Leaks

The so-called “light leaks” and their shadowy brothers aren’t actually caused by the compiler casting rays through walls and ceilings; rather, these are an inherent artifact of Quake 3 lightmaps. Lightmaps are simply compiler-generated images that are blended with the textures to darken, lighten and/or color them. In Quake 3 and UrT lightmap images are restricted to 128×128 pixels (and uncompressed TGA, which is an issue in itself) and usually a single image is cut into many pieces, each covering a specific small area. “Small” is of course relative here, the lightmaps have to be scaled up a lot — even at _lightmapscale 0.125 one pixel has to cover 2×2 units of surface.

A typical lightmap image (a map usually contains a few dozen of them). The color splash is caused not by a light entity but a nearby bright-colored surface coloring the reflecting skylight (only happens with -bounce).

The compiler tries to map surfaces that are similar in proximity and directionality onto continous lightmap pieces — i.e. a floor and the ground outside (even if these are separate brushes with a gap between them) might be covered with a single lightmap piece. The stronger the lighting contrast is the more the lit side of a single lightmap piece tends to “push” into the shadow (a common knowledge among mappers is that the best way to avoid light leaks is keeping light levels the same throughout the map, which of course can make it look bland and boring).

This is what causes light and shadow leaks. The distinction is subtle but important — were the light actually leaking through solid brushes there would be nothing you could do, but forcing the compiler to map things differently is dead easy.

Let’s take the most common scenario: a room with light leaking in from under the walls. To fix this, you simply select the affected floor brushes and make them a separate func_group — this forces the compiler to map this surface separately. Quite often this is enough in itself, but if you still see some leaking (this time because the lightmap can’t be scaled to exactly cover the whole surface at this lightmapscale) you can specify a separate _lightmapscale for the func_group (0.5 is good enough for most cases). This method solves the vast majority of light and shadow leaks.

There are some other ways a light leak can happen though, for example if you have a sky brush resting on top of an accessible building you definitely have to caulk the underside that’s touching the roof. (This kind of leak is in fact as close to light travelling through solid brushes as it gets.) Of course, if you see a very bright and obvious leak that resists all your attempts to get rid of it you most likely have an actual gap between the brushes;-)

Note that it’s impossible to fix leaks from under (rotating or sliding) doors — entities like these are completely ignored by the compiler and the light indeed does behave as if there was nothing in the way. Your best bet in those cases is ensuring that the light levels on both sides of the door are as close as possible.