Making [Q4] Kats Klorr #1

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.

Preamble

First a few shots from GtkRadiant (Quake 4 Edit) showing the ‘box out’ of the map (initial block-out of the level using simple brush volumes) which was used as is and converted to ASE (see below) . This was then imported into Blender 3D to be used as a template from which the actual model was made (using Radiant brushwork as a model template which can be used for ‘scale’ as well as a base object to manipulate).

Design note: using Q4Edit has the advantage of brush volumes being directly exportable to OBJ, else the block-out has to be compiled and converted the traditional way using Q3Map2.

The shots below don’t show the whole model, only a section completed and the one about to be worked on – the purple ‘square’ section top right – is a section of the imported brushwork template. The advantage of using GtkRadiant brushwork converted to ASE (using Q3Map2) is that it’s ‘cleaner’ requiring far less work to delete the often hundreds or thousands of ‘dead’ faces that exporting to OBJ would create when using Q4Radiant.

GtkRadiant Shots

The following show the brushwork layout which serves the purpose of being prepped for conversion to ASE using Q3Map2 (using the exact same approach used to create map object models), with the original brush work later being used to form the ‘caulk hull’ into which the modeled sections will go. With a bit of judicial portal placement the ‘angular’ design of the hull should allow a much more ‘calculated’ effect on what’s being drawn to screen by the Doom 3/Quake 4 engine (idTech 4).

One of the downsides to pre-planning like this is that it can sometime make a level feel a bit too planned or premeditated. It’s necessary to do this now for level design using the Doom 3 engine however, because VIS isn’t automatic like is was with Quake 3; VISibility is managed in a way that’s essentially akin to the manual hint brushing maps for Quake 3 powered games, which has its Pros and Cons.

Modelling The Level

The shots below show the basic contours added to the mesh to describe interesting visual features based on the type of rock surface wanted. On the extreme left can be seen a section of the original converted brush volumes, these are essentially split, cut, subdivided and then shaped to form the desired rock/organic surfaces – initially just a few loop cuts are made allowing the block-out to be roughly reshaped to ‘destroy’ the objects original blocky appearance, which is then further edited with more cuts and shaping to suit the desired look.

UV Mapping

The following screen-shots are from the same area as shown above. Due to the long length of the walls relative to their height, a 512×1024 texture is used (the one shown is a placeholder, ivy needs to be removed although it shows the correct style of rock). A standard Point Lamp has been placed into the Blender scene and a basic viewport snapshot taken showing the various shapes and forms now modelled in the same area of the map discussed above. Below is a lit smoothed render of the model in Blenders 3D View with this single Lamp set-up.

Below a 3D View snapshot showing the general orientation of the rock textured as UV mapped to the area. Rather than being mapped to a single giant UV, its been broken down and split into multiple smaller sections to better facilitate the UV’s following the structures contours in a way that loosely confirm to the way the mesh/UV’s are split; wherever a ‘smooth-group’ was needed, the mesh was broken. Doing this means that certain areas remain unbroken and seams are more or less hidden in joints, cracks and crevices (areas where there is an acute angle between faces not normally visible to the player (the convergence of opposing polygons is used to create/hide a smooth group line/edge break).

Design note: there’s only one Blender material being used so the textures are mapping directly onto the mesh instead of using different materials. The reason for this at this stage is that the textures act as a guide for vertex painting (which will be done later so the model can have blended (mixed) textures in game – where ever a gravel texture is to appear the mesh will be vertex painted  black, the stone/rock textured surfaces left default white.

Initial Brush-Based Block-Out

It’s probably a good point here to show a couple of shots from Blender of the model as it was when first imported into the 3D application; as mentioned previously it’s just a series of boxes.

Because I was using GtkRadiant under the Q3 settings (still working on a project that requires GTKRadiant to be set up like that) I could take advantage of something ASE models converted from a compiled BSP don’t have that OBJ files export directly from D3/Q4 Edit do have; ‘dead faces‘.

Converting a BSP map to ASE generally produce ‘clean’ models; it only converts and exports the faces that are textured or haven’t been merged or culled during the compile process. Because Q3Map2 is very efficient, ‘dead faces’ are removed from the resulting mesh conversion leaving only the faces that are actually needed.

D3/Q4 Radiant exported OBJ files don’t do this; every face is exported regardless as to whether it has a texture on it or not. This makes tidying the resulting model time consuming and messy because the dead faces have to be manually removed or merged.

Design note: Be warned, if you block out in a Q3 editing environment some of the measurements are slightly different; D3 and Q4 player models are slightly wider and taller so you do have to keep that in mind, especially for architectural (man made) maps.

The black lines on the box section above show the initial polygon divisions of that area; they *usually* follow the general shape and contours of the object. It’s these lines that are used to start the manipulation process, shaping the area relative to the look that’s wanted.

The inside of this template looks like the image below, which is lit with a single point light in Blender so the shapes and general profile can be distinguished better. It is in effect the limitations or boundary where the caulk hulled brushwork will be.

Block-Out Level Template

Although this is from a different section of the map it illustrates what happens next; the template mesh is duplicated and used as the basis from which to model the map itself – ‘green’ is the template, ‘pink’ the modelled map object. Everything is pulled inwards away from the walls; going outside that means re-jigging the brushwork back in the editor to fit and changes made which can be quite fiddly so it’s best to avoid doing that, essentially it’s a good idea to make sure there’s enough room in the blocked out template to allow manipulated ‘depth’ where needed.

YouTube Video

What you’re seeing in that video are the initial sections the mesh has been broken down in to. Right now it’s actually based on smooth-groups and not portal splits – that means the mesh is broken up based on getting smooth transitions over poly’s without the nasty hard edges where splits and joins occur, so a corner that perhaps wraps around from one area to another is left as one piece otherwise ‘breaking’ it would create a hard line which would be noticeable in game.

Because the sections *are* based on smooth groups it may mean that they may change at some point in the future depending on how they behave in relation to ‘overdraw’ once placed inside the pre-portalled caulk hull.

Using Blender For Some Lighting Tests

The shot below shows how using Blenders ‘shaded’ view can come in handy for testing some basic lighting setups.

One thing to keep in mind doing this is that the light approximates the way Quake 3 or ‘light-mapped’ games would be lit, which means the light is much ‘softer’ (vertex lit) in the 3D viewport; it doesn’t have the hardness and high contrast that Quake 4’s dynamic lights will eventually produce in game, but it’s enough to get a basic idea of where the lights should be placed.

Vertex Painting

Where ever you want a set of textures to blend together – ground blending to grass for example – a mesh need to have vertex painting applied to it. The ‘trick’, if it can be called that, is to have a ‘common’ texture that’s used as a blend with several other ‘main’ textures; in this case ‘rock’ and ‘ground’, both of which blend to a ‘dirt’ texture. Where ever the mesh has black painted vertices one texture gets applied; where ever there is ‘white’ the other is applied.

For more details on this read the texture blending tutorial here.

So in the shot below the vertex painting has been done so that the ‘dirt’ texture will be the common material between both sets. You’ll want to make sure that when you UVW map the objects that where possible both ground and rock surfaces are UV mapped together.

The reason for this is so that the textures align properly to each other when the blending happens which makes seams in the mesh less noticeable Speaking of which, always try to ‘hide’ seams or mesh splits in areas that you’d naturally expect to see a hard edge as this makes seeing a seam more ‘believable’ when it is seen by the player.

Design Note : If you looking at this and NOT editing any id tech games then you need to look into how the game you’re editing ‘blends’ textures, or if it does indeed do that; a fair number of games UV map unique textures to models so the image itself will have the blended transition from one type of image to the other.

Model Collision

Once the main feature objects have been placed some work can begin on adding collision to the models. Although models like the steps shown below can be left ‘as is’ for the game to work out collision (based on the data ‘compiled’ to the *.cm file), it’s generally better to add a collision ‘hull’ over the object to keep things ‘optimised’ (read that as ‘simple’). The collision model is usually a fairly basic shape relative to the parent object (the wonky, broken steps in this instance) which approximates the general contours and shape of the parent mesh as closely as possible.

The main reason for doing the collision as a model is that it’s often very difficult to shape brushes to ‘fit’ models when they have been manipulated so the  lines, faces and profiles of the mesh no longer fit Radiant’s grid, often with the result that brushes break, or that players get stuck on tiny none-visible edges where brushes don’t match up exactly.

There is a second reason for doing collision on certain things like this; for some reason brushes covered in any of the various ‘clip’ materials – weaponClip, playerClip and so on – often react inconsistently with copious amounts of modelled geometry resulting in the player being able to jump through the models and occasionally through caulk brushes and out into the void. Modelling collision hulls doesn’t fix the problem completely but it does appear to reduce it better than using clip brushes.

The steps, as with everything else so far, were modelled from a template object converted a BSP file to an ASE model and then imported into Blender. As with the main map structure the template acts as a guide to shape the steps from. Also at this point it’s worth noting that the leading edge of each step has been ‘beveled’ to stop it from causing bad shadow problem in game due to smooth groups 

Player Size

In terms of the information covered so far in this topic this should be done as part of the initial stage of production rather than using them now (relative to this topics development history); player size templates.

Although player models have various sizes and proportions, which differ from game to game (Q4 is slightly larger than Q3 for example), it’s always a good idea to have some sort of physical representation present in the level as you model so you can check your general environment proportions in relation to the players width and height; this saves having to go back and readjust elements of the model later on once you start running around only to find out that you can’t actually fit through that gap in the wall you intended (eat fewer donuts Ed.) as a shortcut to another area.

The simplest thing to do is to load a player character into Radiant and place a brush over it (can be the actual model or the editors entity block) so that it covers the general proportions and then export that to OBJ or convert to ASE as previously mentioned. If the actual unit proportions of the player character are known then use those to draw out the template.

Once this template is in Blender it can be duplicated and placed at strategic points to act as a constant reference for size. It doesn’t need to be textured because it’s nothing more than a ‘helper’ and won’t be exported as part of the level.