Content is copyright © KatsBits™ 2000-2013. All Rights Reserved.
No part of this web site may be reproduced (except for personal use) without prior written permission from KatsBits.com. For more infomation on copyright click here.
BSP brush volumes and patch mesh objects were never really intended for making complex or small fiddly shapes, they tend to work best as larger blocks, volumes and shapes. This leaves the level designer with a bit of a problem; just how can that fiddly detail or 're-usable' object be make with brushes? The straightforward answer to that is to simply convert the object into a model which can then be used 'as is' or further refined in a 3D application like Max, Maya or Blender.
The use of models in levels helps optimise the compiled map in a number of ways, mentionioning a few they;
Often have better 'smoothing' than can be had using a 'phong' shader, by default brushwork doesn't have smoothing (mesh smoothing) or smooth groups, that has to be added using special shader surface parameters that add a uniform value to all objects.
If replacing patch mesh objects, models are often have a significantly reduced poly count. Again by default patch meshes have a fixed row/column relationship which means the more complex the curve the more polygons are needed to describe that curve (idtech4 engine allows changing this).
'Optimises' the compiled BSP due to the presence of less BSP data.
There are a couple of important key principles involved in this process of converting brushwork, one of which is 'position'. The physical position of any brushwork relative to Radiant's 0,0,0, grid centre is important because that point, grid centre, acts, and will be interpreted as, the eventual point of origin of the model; this is the point around which a model is usually rotated and manipulated (re-sized etc.). For more information on this point see "object centre and bounding box rendering" below.
Models and entities 'break' if their origin point is buried or occluded in structural brushwork often returning a 'leaked' map during the compile process - structural brush volumes are treated as being 'solid' because they seal the internals of a level away from the 'void'. This means that when prepping brushwork it's best to 'over-compensate relative to the eventual use of the model in the level.
For example, the brushwork platform shown in the image above has been aligned to GTK Radiant's 0,0,0 grid centre to allow plenty of room for the support struts to be buried deep into the uneven surfaces of a brushwork rock face without blocking or otherwise interfering with the models point of origin. From a practical point of view this means making the support beams longer, or, shifting the brushwork before conversion so the origin point is on the 'outside' of the object.
Game engines tend to process and render models on a 'per object' basis, not a 'per polygon' (there's a difference between how assets are loaded in for use and how that data is rendered to screen - be mindful not to confuse the two). What this means is that a model will be processed in it's entirety if any part of it is visible, even a single small polygon being seen will result in the whole model it happens to be part of being pulled into the game and processed, this is because the model, the 'area' or 'volume' the mesh occupies, is contained within something referred to as a 'bounding box'; in effect it's not the model that causes the entire mesh to be drawn if seen but the bounding box, the volume occupied by the mesh as a primitive shape (the red outline shown below).
It's important to understand visibility here because it relates to how brushwork is set up for conversion. As mentioned in the previous section, models are processed and rendered relative to their bounding boxes and not the models structure. As such this mean that large models will need to be broken up into sections (and put back together in the tools) so that only parts of it are rendered at any given time; leave a model too big and it'll be rendered from the other side of a level if only a tiny portion of it can be seen, and by "seen" that's meant in relation to what the engine reads as being "visible" at any given time. Or more correctly, what "VIS" calculations tell the engine is visible.
A simple way to illustrate this would be to place the tutorial model behind a wall as shown below. As this is a 'structural' volume it blocks visibility, meaning VIS calculations have determined that the platform isn't visible from the cameras current point of view (player) so it hasn't been loaded in for use.
On the other hand, if the player is in a position to see even the tiniest part of the models bounding box (the red outline visible in the image directly below) the engine will pull the entire model in for use regardless as to whether the player can actually see the structure of the object itself or not (also as shown below). What this means for converting brushes into models is that you have to be mindful of the size of the object relative to it's intended use and position, compensating or adjusting the collection of brushes to allow for 'abstract' use (unplanned). In other words, it's usually best to keep model sizes down.
The downside to splitting large objects up to accommodate better VIS'ing is that brushwork then has to be re-organised in such a way that each part re-align itself to its neighbour correctly in the editor, game or 3D application, often whole sections of brushwork will need to be moved and re-centring at 0,0,0.
To minimize problems whilst doing this make sure snap to grid is 'on' in Radiant and the 3D application being used to do any further editing - break brushwork into sections, re-centring to the editors centre point and then exporting each unit out for further work, the advantage being that each exported section is 'grid locked'. Alternatively the entire map can be exported and then sectioned it in your 3D application, the advantage here means any further editing done to the mesh will perfectly match it's neighbouring section when time comes to break the model down into smaller sections prior to final export.
An object rotates around the point of origin so having that placed in an odd position as a result of where the brushwork was placed relative to 0,0,0, grid centre may adversely effect how models are manipulated, tiled and connected to other models. Where ever possible try and centre the point of origin at the objects centre of mass - if it's an individual object, or relative to the other sections or models it may need to be (re)connected to.
The basic principle of getting a model from a map is to compile it in the same way as is done with any other type of BSP or Q3Map2 compiled 'map', the resulting *.bsp then only needing a further 'format' conversion to *.ase or other supported 3D format.
As mentioned on the previous page, the brushwork to be converted needs to be encased in a caulk box, a 'hull', into which is placed an info_player_start. From this point it's best to optimise brushwork by stripping out any game related entities (with the exception of the info_player_start), as well as removing any excess or unnecessary brushwork. It's also good practice to caulk all hidden or unused faces so they don't get exported.
The key here is optimisation, ideally the model needs to have as few faces as possible else it'll cause the engine to render 'waste' - faces that don't actually serve any purpose, i.e. they don't add to the structure or appearance of the object in any way, nor do they help in any 'technical' sense.
There is a caveat here however. Models tend to need to be what are referred to as 'closed meshes', that is, it's important that they ordinarily don't have any gaps or holes in them. So whilst converting brushwork in this way to produce models may work within idtech powered games (because it can generally handle 'open' meshes), the same may not be true of other technology. As a result, if a models has the potential for being used elsewhere it's always best to cover what were to be hidden faces with a 'miscellaneous' texture of some description so they get exported correctly. This then facilitates those face being easily managed as a group - applying a shader to them in another engine, or selecting the group based on material assignment and so on.
If you have access to Doom 3, Quake 4, Prey, Quake Wars, or any game running on idtech4, the editor available for those games, QuakeEdit, can export brushwork directly out as *.obj formatted models. The downside is the action will export everything selected including entities and hidden/caulked faces. Using this process will mean paying more attention to 'cleaning' the brushwork before export. Bear in mind also that brushwork saved from QuakeEdit only exports face data - UVW maps, material and texture information may be lost as a result of the process.
To export models from QuakeEdit select the brushwork and click "Selection >> Export >> To OBJ". In the dialogue window that opens, type a file name and click "Save". If the brushwork belongs to a *.map created in or for Quake 2, Quake 3 or some other idtech based technology, then it may be possible to 'import' those types of maps directly into QuakeEdit using "File >> Load", the map will be processed and converted into the correct brush format as it loads ("Brush Primitives"). Export as described above.
Alternatively, it's also possible to export brushwork from GTK Radiant 1.5 via the OBJ export plug-in - select the necessary brushwork and then click "Plugins >> brushexport2 >> Export selected as Wavefront Object", click "Save" in the box that appears. As with exporting of any kind of brushwork, make sure to clean the file properly of any 'entities' and elements. The ability to export from GTK Radiant may not be available in other earlier versions of the editor.
There are always caveats to converting brushes in to models so the level designer needs to be aware of those as discussed in this tutorial. To summarise;
Models may 'break' if the Point Of Origin is buried within (structural) brushwork (the model may 'break' irrespective as to whether the origin point is submerged in 'solid' structural brushwork or not).
Incorrectly positioned models may exhibit lighting artifacts due to occluded faces.
Models are rendered based on their Point Of Origin position (the 'origin point' is not to be confused with a models 'centre of mass') in direct relation where that is within the objects overall bounding box limits.
Models are usually rotated, moved and position based on the Point Of Origin.
Be sure to strip out all game specific entities, caulk hidden faces (unless the model is destined for use elsewhere), and un-group brush based entities back into raw volumes.
Be aware that breaking large models in to sections may inadvertently create smoothgroup issues when put back together due to the way lighting is then calculated for the individual sections rather than on the whole collection as a larger unit.
Detail flagged brushwork can be left 'as-is' because it's ignored by the process.