Make models from BSP brushes or maps (export maps as models) - advanced

Converting *.map brushwork to models

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.

Brushwork position ^

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.

Brushwork placed at grid centre to ensure it doesn't break when buried in a map

Brushwork placed at grid centre relative to how it's going to be used in a map. Make sure to compensate for uneven surfaces so allow a large 'waste' area on the model

Structural brushwork and 'breaking' models ^

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.

Eventual converted brushwork being used buried in a map

Eventual converted brushwork being used buried in a map, the origin point being correctly positioned before conversion means being able to place the resultant model in many situations and on uneven surfaces such as a rock face

Object centre and bounding box rendering ^

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).

Model rendered and processed based on it's bounding box, the red outline shown

The converted brushwork shown as a model in the camera view of Radiant. Shown is the red outline of the 'bounding box', the limits by which the model is processed by the game

Model bounding box in Radiant

Red outline showing model bounding box in Radiant

VIS(ibility), brushwork and models ^

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.

Structural wall blocks object visibility as a result of VIA calculations

The structural wall blocks the model, the game has (more accurately, the VIS part of the map compilation process has) calculated that it can't be seen by the player standing where they are so it won't be pulled in for use

The object where it actually is in relation to the wall

Model selected to show where it actually is in relation to the wall

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 models bounding box is visible so the engine loads the entire object in for use

Selecting the object shows that it's not actually visible to the player and yet, due to the bounding box being visible the entire item has to be loaded in

Sectioned meshes and grid position ^

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.

Section large objects to make them more efficient

Section large objects to make them more efficient, instead of forcing the engine to load one large object, it's better to facilitate incremental loading by breaking the big models in to several smaller ones

Origin point and object rotation ^

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.

Origin point acts as rotational axis in Radiant

Origin point acts as the axis in Radiant around which the model is rotated

Brushworks 0,0,0, position translates to axis of rotation

The same origin point in a 3D modeling application around which the mesh rotates

Optimising and prepping brush work ^

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.

Caulking hidden and unseen faces of brushwork before being converted into a model

Caulking hidden and unseen faces of brushwork before being converted into a model

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.

Texturing hidden faces so they *are* exported

Using a different texture on hidden faces so they export and make a valid 'closed' mesh for use in a different context/engine other than idtech

Exporting brushes from Doom3Edit, Quake4Edit et-al ^

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.

Exporting brushes from Quake Edit

Exporting brushwork from QuakeEdit using the inbuilt option

Exporting brushes from uakeEdit to OBJ

Saving a selection of brushes from QuakeEdit as an OBJ formatted model

Exporting brushes from GTK Radiant 1.5 ^

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.

Exporting brushes from GTK Radiant 1.5

Using GTK Radiant 1.5's brush export plug-in

Saving brushwork to OBJ from GTK Radiant 1.5

BrushExport plug-in which will save selected brushwork to and OBJ format model

Conclusion ^

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.

^