[Q4] Kats Klorr - development

Kat's Klorr Quake 4 level development

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.

Inside the mesh showing some early details (later removed for game-play reasons)

Inside the mesh showing some early details (later removed for game-play reasons)

Partially complete level in Blender showing 'organics' and original block-out

Partially complete level in Blender showing 'organics' and original block-out

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.

Brushes textured so only the faces needed are visible

GtkRadiant 'wireframe' showing the active brushes that will be exported to ASE (caulk is hidden from view revealing the necessary textured faces that will eventually be converted for use)

The 'hull' shown ready for conversion to a Blender importable model

GtkRadiant 'wireframe' (selection wireframe highlighting) showing the larger caulk hull around the entire level required for converting a BSP'd map into an ASE using Q3Map2

Brush-based hull in Radiant (Q4Edit)

GtkRadiant 2D viewport showing top down layout of the brushwork used to create the basic level structure. Not much is distinguishable due to the basic blocky layout of brushwork

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.

Some basic loop cuts are placed and basic shape formedAdding more loop cuts to detail the meshMore loops and detail

A series of loopcuts, some obvious, other subtle, are used to redefine the appearance of the mesh so it appears more rock-like and organic

Block like structures being remodelled

A slightly clearer view of the final(ish) version of the room (area) shown above - it might undergo some tweaking but that's pretty much it (note the addition of steps bottom-right)

Adding more organic structural detail

The blocky corner volume remodeled to form an smoother organic rock-like structure

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 512x1024 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.

Finalised structure ready for UV mapping

Finalised structure ready for UV mapping

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 UV unwrapping and texture application

Initial UV unwrapping and texture application

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.

External view of brush-based blockout in Blender

External view of brush-based block-out in Blender - This shot shows the raw model block-out 'template ' which started life as brushwork (as shown on the previous images above)

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.

Basic block-out imported into Blender

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.

Shaping the level from brush block-out

Shaping the level from brush block-out

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 test ^

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.

Basica lighting test in Blender

Use standard 'lamps' for this as they roughly approximate 'point lights' used in Quake 4

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.

Black vertex shading used for texture blending

Black vertex shading used for texture blending

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 - weaponClipplayerClip 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 

visible mesh without collisioncollision mesh in place over 'visible' mesh

The image above shows the original template duplicated and UV mapped with a 'collision' place holder image. The material file for the steps in game will have the surface parameter "nonsolid" - this will allow weapon fire and/or player movement to 'pass through' the any surface marked as such - which is why the collision model is needed

primitive collision mesh

Shown above is the simple collision model itself. Because this is a collision model for a map object it can be a little more complex than the same sort of thing on weapons and entities, those can't exceed a given number of triangles, using 'standard' step height/width here means physics are 'normalised' - what you'd expect if running up a flight of stairs made from brushwork. As can be seen for the image below it's nothing more than a 'skin' rather than a 'volume', as would be the case if it were a brush

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.

player scale

Player 'capsule' shown relative to the step model in Blender

KatsBits Web
Search KatsBits using StartPage