Back to tutorial index page

Pink Power

(A discussion on approaches to lighting techniques in multiplayer levels for Quake 4 and other aspects of level design)

Please note: screen shots included in this article were taken running Quake 4 at a screen resolution of 800x600 on high settings, by a machine using an XP 2500, 1 gig of RAM and an FX5600 video card. For this computer 40 to 60 frames per second (fps) is very good. 20 is acceptable and whilst still playable 15 fps and below indicates problem performance.

General belief is that multiplayer levels should be lit primarily by ambient light. Details are picked out by 'normal' shadow casting light entities. My feeling and premise for this article is that this approach removes the most powerful and artistic feature of Quake 4 technology, its lighting. To me, ambient lighting appears flat and unnatural. Surely there must be another method. I intend to demonstrate that there are far superior techniques that result in a more attractive overall finish and do not negatively impact upon performance.

In developer mode if one enables r_showlightcount visible faces are drawn in single coloured blocks. These colours represent the number of light volumes that a player looks through that strike each surface. Common belief says that the higher the number of light volumes, the more performance will be impaired. The lighter the colour of the rendered faces, the more light volumes present. Pink and white represent especially serious problems. I intend to show that this theory is an over simplification. It is not the number of lights present but the number of shadow casting light volumes that caused the problems. Below are examples of the same test map lit with different combinations of light entities.

In order to test and prove my observations I built a very simple test map. The map was lit using three methods. The first was illuminated with shadow casting lights, the second with ambient lighting, supported with light entities picking out some details, and finally the last test was done with non-shadow casting lights. In the first and third tests exactly the same amount of light sources were used. In the ambient light test one less light entity was used than in the other two versions.

In each test the player is stood in the more-or-less the same position. In game shots were taken running the game normally and then with r_showlightcount enabled.

To begin our closer examination first look at the light set up in the editor which is shown below.

The light entities and their respective volumes are highlighted in the above screen capture. The placement of lights is deliberately over done so as to emphasise the issues arising from over lapping light volumes. Bear in mind the placement of the light entities above in each of the screen shots below.

Test 1

The image above shows Quake 4 in all its shadow casting glory. The texture detail is good, with well lit normal mapping working as one would expect. However, the fps in the top right hand corner demonstrates the strain the engine is placing upon the computer.

When examining the number of lights affecting the visible surfaces we see much of the map is pink. This indicates that the player is looking through too many light volumes and hence the poor game performance.

Commonly held opinion on game lighting seems to be supported here.

Test 2

The shot above was taken with the same test map lit primarily with an ambient light. The increase in game performance is obvious if you look at the fps. However, the texture detail is seriously impaired. Normal mapping looks flat and the game loses the special artistic quality that it possesses.

Looking at the light count it is possible to see an immediate improvement. One less light source was able to be used in order to achieve the same level of illumination. In fact it would have been possible to remove many more lights and still have a perfectly playable level in terms of general light level.

Once again, commonly held opinion is bourn out.

Test 3

The shot above for me is the crucial point of this discussion. This is the test map lit by normal un-textured lights, but with shadow casting turned off (NB: the option for disabling or enabling shadow casting can be found in the light editing window). Note that the fps is exactly the same as when the ambient based method of lighting was used. The textures and normal maps, in my opinion, look far  better than in the ambient version of the same map. Certainly it would be possible with the careful placing of a few shadow casting light sources to achieve the same look as the first test. Now let's look at the light count image.


Its all pink! A map that pink should not, so commonly held opinion tells us, perform as well as a map lit through the use of ambient lighting and fewer light entities. Yet it plainly does. Not only does it perform as well, but it also retains the ability to utilise fully the stunning rendering capabilities of  Quake 4.

My conclusion is simple: Ambient lighting is a tool that could be seen as, and indeed most often is used for, lazy mapping. Does that sound harsh? That is not the intention here. The point is that it is far too easy to throw in a large ambient light source and not bother to spend time correctly lighting a level. The theory that multiplayer maps have to be lit this way in order to maintain performance is simply not true. Since the Quake 4 1.3 point release if 'professional' players insist upon absolute top game performance it is possible to set the CVAR r_forceambient to 1. This option switches off all lights so that the entire level is lit with one uniform ambient light source. The resulting appearance, to my mind, is flat and unattractive but does offer performance completely unhindered by the restriction imposed by all normal light sources.

Now, go forth and light levels artistically and beautifully, with no loss of performance. Show the community what Quake 4 can really look like. Paint your maps pink, and be proud.


Quake 4 and phong shading (smoothing)

Unlike Quake 3, only patches and models can have phong shading (or smoothing) in Quake 4. I came across this little problem when working on a level for the id Software Community Map Pack contest. I needed a natural looking cave area but the rules of the contest prohibited the use of custom made models. To begin with I constructed my area from brushes by tri and quad souping, a technique die hard Quake 3 mappers are familiar with for producing organic looking geometry. The result looked pretty good but presented two insurmountable problems. The brush work, unable to be smoothed, looked somewhat sharp and unnatural and the texturing was poor as each brush is considered a separate object.

I stumbled upon a neat trick to solve these problems.

It is possible to create a patch mesh and then reduce the subdivisions to 1 on both axis. Then collapse the vertices so that the patch is either a rectangle with 4 vertices or a triangle with 3. It is still possible to apply a texture the patch without distortion. Even better was the fact that over a number of patches selecting cap or naturalise in the texture options would apply the texture across the group, rather than to the individual face. Another useful feature to have discovered is that it is possible to select patches that meet square on and use the combine option from the patch menu to unite the objects into a single patch. This feature does seems a little buggy. Often it inverts the patches, sometimes it messes up completely; so save your work before each use of this function! By working your way through your patches, joining 2 at a time, it is possible to create a single large mesh, with each face contributing only 1 or 2 tris.

The two images below show combined patches selected. In the second picture note how the control points are linked together in the more complex shape. I attempted to make each section of my cave the same size at the texture I wanted to use in order to simplify scaling when that texture was applied and aligned.

Once the patches are combined into a single object it is then possible to set the texture scale across the entire mesh. In some cases it is perhaps a better approach to build your area with the texture size and scale in mind so that no re-scaling of the texture is required at all. Quake 4 collision issues are overcome by placing the new mesh directly on top of the original brushes (now completely textured in caulk). In order that Quake 4 renders the mesh correctly it may well be necessary to turn it into a func_static. The engine then treats the mesh as a model rather than trying to split it up as it would brush work. The really pleasing result arising from this approach is that the finished mesh will be phong shaded, smoothed and natural looking.

The one area where models would have an advantage over this form of mesh is in texture blending. There is no way to vertex paint our simple patch mesh. However if you where to create a mega-texture style texture,  blending images together in a paint program, specifically to fit the size and scale of the mesh, the outcome would look exactly the same.

For mappers who have no inclination to learn to use an external 3d modelling application, or for small areas of terrain or that are required to look organic in appearance, this technique might well be useful.

Pictured below is an in-game screen shot of the finished mesh: