Making [Q4] Kats Klorr #4 – Optimisations

Developing game levels is often a long and protracted process, especially where the level and it’s contents are based on customised content, i.e., built models, textures and so on. The following is a partial walk-through of the process to build a custom level for Quake 4. All content was modelled using Blender 3D.

The contents of this article were originally posted several years ago to a now unavailable forum. Some minor editing for clarity has been performed.

Quake 4 & portals

Portals are probably the biggest cause of confusion and frustration when editing Quake 4 and other idTech 4 games than any other aspect of the process, it needn’t be when looked at in a much more simplistic way than it’s normally described. Take a look at the shot below and note the red lines, those are Portals and basically act as ‘boundaries’ or ‘barriers’ between different ‘areas’ or ‘zones’ within the overall level.

An easier way to explain it is to imagine that each red portal line shown below is the side a cardboard box. As you move through a map it’s basically composed of a number of these cardboard boxes all butted up to each other; the red lines being places where the boxes connect and share a side. What you then have as a result of that is in effect a series of ‘areas’ (‘volumes’) defined by the sides of all these boxes.

Lets assume that all the boxes are sealed so when you stand inside one you can only see the contents in that specific box; the question then needs to be asked “how do I get into another area?“. The answer is simple; through one of the sides, you’d cut a hole there so you could climb through into another area. In doing that it now means you can see the contents of this new area and the contents of the old, keep doing that and eventually you can climb through and see the contents of every box.

Being able to see the contents of each box like that is ‘bad’ in editing terms because it means you can see all areas of all the boxes regardless as to which one you are standing in; look one way and you see everything, look another and you still see everything.

To overcome this the sides of the boxes have been given a special property; they open and close depending on where you stand, this equates to the sides between two boxes disappearing as you walked through it and reappearing when you were far enough away from one for it not to be seen if you turned around. As you walk through the boxes they would each in turn open, make visible their contents, and then close when you weren’t near it; standing on one side of a map means a boxed area on the other side won’t be drawn any more.

That’s the basic principle of portals their placement and how they work, there are more technical explanations on the web but they often over complicate the process relative to what a level designer needs to know in order to use and place them. If you keep in mind the ‘boxed area’ principle, adding portals shouldn’t be too difficult to understand; each portal textured brush (portal texture on one face only and nodraw on the others) is used to define an area which then determines what should be drawn to screen as the player wanders through a level – each ‘box’ is drawn and hidden depending on the players where about’s.

Portals in game

The series of shots below show portals as they work in game. Red are ‘closed‘ – nothing beyond them is drawn, and green are ‘open‘ – content behind them is drawn.

It important to point out here that there is a lot more going on in terms of what the game engine is doing when it comes to actually drawing what you see to screen, especially in relation to map models and other large objects.

Although as described above portals create ‘barriers’ past which nothing is drawn if it can’t be seen, in relation to models the game does not create a hard split along surfaces if they intersect a portal; in other words a closed portal won’t slice through the model geometry completely like a knife cutting through a block of clay. This is why it’s so important to optimise models by breaking them down into smaller map objects; because they are being processed per object and not per polygon all a closed portal will do is stop the drawing of objects behind it rather than objects that intersect it, so leaving a map model as one big object means the engine is processing the whole thing in one go and all the time. Keep this in mind as you look at the images below.

The image below should really be looked at in relation to the source files for the models but as those aren’t available yet we’ll make do with just the screen-shot. If you look carefully at the shot you can notice that a few triangles appear to end quite abruptly, that’s because only that particular model section is being drawn with subsequent sections in the sequence remaining unprocessed until they are needed on screen. So looking at the image anything within the green and open portals is being seen and drawn to screen, if the section of a model extends beyond a closed portal it too will be drawn simply because part of it is potentially visible.

Dynamic Shadows optimisations

Although lighting has been discussed before it was in the context of an overall ‘ambiance’, shadows just being part of that process. The map is now at a point where performance and final tweaking needs to be considered, shadows are an important part of this process. Deciding whether to leave dynamic shadows enabled is always a tricky question to ask but for multi-player maps where performance is relatively more important than appearance (single player levels don’t have the same prerequisites as multi player levels) it’s always a better idea to leave them off.

The following is a good reason why; it’s far too easy to kill a good maps visuals by ‘bad’ performance caused by shadow casting light volumes, and this is despite being able to disable shadows via the main game menu or the use of r_forceambientlight 0/1 to remove all the lights and use a single 100% bright ambient light which makes the level look like the old ‘overbright’ appearance of Q3 maps compiled without lightmaps!.

As an example the shots below show the same area with and without shadow volumes active; the FPS in the top right is more or less indicative of the actual FPS. In the specific case of the map discussed in this dev diary, shadows were left disabled for performance and for visuals. The area show contains 4 light entities, one of which is a level wide fog light (a light with a thin fog applied to it that covers the entire level); an ambient light at the very top of the room where there is a ‘skylight’ opening, this simulates the brightness caused by being close to the opening; a ‘directional’ point light to simulate the direction the light is coming from (the skylight); and a ‘lantern’ light acting as light emitted from the stone lamps at ground level.

Taking a closer look at the two images below reveals there’s actually very little difference between the two in terms of how the area is being lit, aside from the hard edges darker areas visible in the bottom image. In other words, the way the light is being distributed around the area, adding or removing shadows doesn’t make any real significant visual difference to the scene and this is one of the guiding factors in relation to whether shadows can be remove or not so aside from that being down to clever use of nonshadowed lighting, it also highlights that shadow volumes are not always an absolute necessity to have in a level.

Shadows & performance

There is a another tool in the level designers bag that can be used in relation to performance and visuals but it doesn’t always have the effect expected as it can make performance worse and not better because of the way the game engine works. Although shadows cast by light volumes can be turned on or off individually this is occasionally not enough, a more ‘global’ approach needs to be taken and this can be done in the form of two surface parameters in a material file;

1) noshadows
2) noselfshadow

What these two parameters do is stop objects receiving shadows cast by lights – shadow volumes falling on surfaces won’t render, and stop objects covered in the material from casting shadows – the uprights of a chair for instance, won’t cast shadows onto itself.

Whilst this may sound like a good way to increase performance by effectively turning off shadow volumes on all the textures applied to surfaces in game, the actuality of this method doesn’t quite work like that. In essence shadow volume calculation is ‘subtractive’, it ‘culls’ (removes) the influence of light on surfaces that would otherwise receive it, for example; the undercut of a rock face overhang that uses a material file with ‘shadows’ on will receive very little or no light at all from a source above directed down.

Remove the ability for the same surfaces to produce shadows and that undercut will then receive light because, although the overhang should physically block the light, the material is telling surfaces to effectively ignore shadow information with the net result of more surfaces being lit and needing to be rendered.

With this in mind looking at the information in the images below will become clearer. The three images below are as follows, normal render, shadows enabled via material, shadows disabled via material. Image two and three show renders based on r_showlightcount 1 being ‘on’; this means the number of lights hitting surfaces are shown as coloured blocks, the more lights the ‘lighter’ the colour – anything above ‘white’ means 5 or more lights influencing that surface.

The difference between the two shots and the change in light-counts is immediately apparent; much more pink and white in shot 3 (shadows ‘off’), even though the general understanding is that turning off shadow volumes on materials should increase performance, it in fact does the opposite and makes it worse.

As mentioned in the undercut/overhang example above, because light volumes are no longer being managed and ‘culled’ it means more surfaces than before now receiving ‘hits’ from lights that had not previously been doing so. As more lights equate to decreased performance this is generally what’s going to happen; a performance drop, in game it equates to between 10 and 15 FPS in this particular area.

The upshot of this process is that although it’s possible to effect shadow volumes and performance in more than one way, it’s not always beneficial to do so, esp when applied on a more ‘global’ scale via materials than is possible with using just light entities.

Normal render

Shadows & overall Performance

This is essentially the third and final part that talks specifically about the use of shadows in Quake 4 MP levels. The thing about shadows is that it’s not that clear cut in terms of trying to improve performance over visuals or visa versa because of the way the engine and shadow volumes work; this next set of images highlight this. The shots below are looking at lighting mainly from a visual point of view, in other words, trying to improve the appearance of modelled objects in game.

To be…

A little bit about how smoothing works. In a nut shell it’s a method of averaging the distribution of light over several faces or an area; that is a group of polygons are looked at and light is distributed over the group according to their relationship with each other; Quake 4 shadow volumes don’t do this at all.

In essence, it’s as if smoothing has been turned off resulting in the ‘faceting’ (hard delineated edges and faces) appearance often seen in a 3D applications viewport when looking at a mesh in that mode – smoothing disabled; Quake 4’s dynamic shadow volumes are more or less doing the same thing and treating each surface as an individually lit plane, no averaging and no neighbourhood relationship between faces. This is where the *cough*’patented’*cough* faceted look comes from (in a none technically explained way), it’s Quake 4 simply lighting/shadowing faces per polygon rather than per averaged polygon grouping the way that smoothing does.

So visually, leaving shadows ‘on’ via the material file (by commenting out or not using noshadows and noselfshadow as described in the post above) often results in very hard edged shadows on modelled objects in the world; terrain sections often have a faceted appearance, made worse by the fact that they make use of a low polygon distribution as a method of optimisation; this is what’s shown in the shot above. Taking a closer look at that crack in the rock face the cross hair is looking at reveals an example of what shadows are doing to the model, or rather how shadows are being produced relative to what the game finds; hard edges.

This happens everywhere and often results in odd visual anomalies similar to that shown below (the area just above the gun sight) where shadows appear as dark cuts or gashes that don’t see to correspond to anything; these are the troublesome shadows because as can be seen in the rest of the shot, the shadows appear to be fine; although still hard edged.

Or not to be…

Looking at the following shots with shadows disabled (by activating noshadows and noselfshadow in the material file) reveals no real difference in light level (how bright it is) or distribution but, take note of the two troublesome area mentioned above; no hard edged shadows and no ‘anomalies’.

Notice that there is still a very good sense of light and shadow because the game is making use of the underlying ‘shading’ (which works pretty much in the same way smoothing does in a 3D app) inherent to models; the absence of dynamic shadow volumes don’t really effect the appearance of the modelled object because ‘smoothing’ (‘smooth shading’) is kicked into gear and is now visible (it couldn’t be seen before because the shadow volumes were more dominant visually). Because shading works the way it does (averaged vertex normal’s) it means that edges and surfaces behave the way they do when in viewed in the 3D modelling application; what you see is what you get.

If you watched the terrain editing video tutorials this shadow problem is the reason why the extra steps in section 8 were done as a way to limit the problem; by adding extra polygons along edges it means shading and shadows have more surfaces to work with and in the case of shadow volumes the extra polygon mean a better sense of softer, shaped shadows.

Incidentally, note the performance difference between shadows being left on and turned off; although Quake 4 seems to have captured the FPS at a ‘display drop’ (when the FPS numbers ‘glitch’ and recover), the overall frame-rate loss was a minimum of 10 FPS overall when shadows were disabled (it was more often more that that).

Final

I’ve finally released this map. I was waiting for 1.4 to come out but the map has already sat on my HDD for two months waiting on that; two months!! Anyway, you can download the map from the following page, Blender source files to come; Kat’s Klorr Q4MP.