[back]Creating a map with Blender 3D (exporting a model to *.map)

Contents - exporting models as maps

• Introduction
• How to export a model from Blender 3D to a *.map
• Exporting the model to the *.map format
• Settings used when exporting models to maps
• Importing the map file into GTKRadiant

Contents - advanced user information

• Prepping the model for export to a *.map
  • Brushes are created as 'thin skin' volumes
  • Brush joints are mitred
  • Maps are exported relative to being 'structural' brushwork
  • Materials, textures and orphaned shaders
  • UVW mapping models in relation to exporting as maps
  • Export quads and not triangles
  • Scaling the model to the right size
• 'Detail' flagging brushes, BSP file size & bot navigation
• Caulk hull building
• General level editing considerations
  • Caulk hull
  • Texturing
  • Snapped to the grid
  • Blenders to Radiant grid spacing
• Conclusions
• Footnote: converting models to maps from 3DS Max and other 3D applications

Introduction ^

With the addition of an export option, Blender 3D can now export meshes and models directly out to the *.map format most often used in games like id software's 'Quake' series. These 'converted' models can be loaded directly into QeRadiant or GTKRadiant 'as is', so it is now possible to 'model' a level for use in game.

This tutorial only discusses exporting the model out of Blender 3D and into the map format so it assumes a model is already available and ready for use, that you are using a version of Blender 3D that includes the "Quake 3 (map)" export script - Blender 2.45 or above, and that you are familiar with the basics of using Blender 3D to create content.

Design note : For advanced user information see the bottom of the page.

How to export a model from Blender 3D to a *.map ^

The model being used for this process is show below, it has a combination of 'curved' ('arched' or 'vaulted' ceiling) and 'flat' (planar) surfaces that make up the physical structure of the object to be exported from Blender 3D as a *.map. It also has materials and corresponding textures applied to different sections of the mesh (in this case separate 'wall', 'floor', 'ceiling' and 'pillar' textures).

Exporting the model to the *.map format ^

Exporting a models from Blender to a map is straightforward and doesn't require some of the usual steps associated with exporting models to ASE, for example.

HOW TO : select the right mesh section

Select the mesh - RMB Click - or where multiple objects are needing to be exported, for best results select each object in turn (export one at a time). Note that multiple selections can be exported at the same time using Shift+RMB to select each section, but where any of those are relatively detailed it's best to export separately.

HOW TO : exporting the mesh

Make sure a mesh is selected then from the "File" menu go down to "File > Export", select and then click on "Quake 3 (map)" ("File > Export > Quake 3 (map)").

This will open the 'file browse' window with "*.map" present in the file name field. Change the file name and / or save location to suit the project being worked on (save the file directly in to the "\quake3\baseq3\maps\" folder, or elsewhere and copy / paste to the "maps" folder). Once done click the "EXPORT MAP" button.

Settings used when exporting models to maps ^

Depending on whether the model was build in Blender to scale or not - that is, at actual size relative to Quake, or using Blenders default object sizing - one or two settings need to be adjusted so the model gets exported and converted to the right size.

HOW TO : map export settings

On clicking the "EXPORT MAP" button from the previous step the "map export" settings pop-up will appear. The main option that need to be changed relative to how the mesh was built is "Scale: [value]".

• If the mesh was built using the reference block pack it means the model has been built to scale, change the "Scale" option to "Scale: 1".

• If the mesh was built based on the default settings Blender uses when it starts then the mesh will be approximately 100x smaller than is required for correct scale / sizing in Quake editing. Change or leave "Scale" at / to "Scale: 100".

Additionally, change "Face Width: [value]" to it's maximum value of "10"; "Face Width: 10".

Click the "OK" button to export the map. The model will then be exported to a named *.map file.

Importing the map file into GTKRadiant ^

In order to open the map properly it's best located in the "maps" folder inside "baseq3" (if creating a map for Quake 3). Once saved, if the file wasn't save there, move or copy / paste it in to that folder location. The exported model will function exactly like a map created in Radiant so can also be loaded (opened) and saved as such.

HOW TO : opening the exported map into GTKRadiant

To open the file into GTKRadiant click "File > Open...", browse to where the file is (the 'Open' dialogue should open by default in the "maps" folder), select it and then click 'Open'. The map will load into the Radiant.

Conversely to save the file click "File > Save" (will overwrite the original file) or preferably "File > Save As..." to create an incremental 'version save' which will allow fixed point regression in case of problems.

Once the exported and converted *.map is loaded into GTKRadiant it can be worked on in the same way as any other Radiant generated level, the brushwork is fundamentally the same so subject to the same build principles.

Advanced user information

Prepping the model for export to a *.map ^

Because Blender 3D (in fact any modelling program) works in a fundamentally different way to the Radiant editor (or any BSP based level editor) it means that a number of very important considerations need to be taken into account, essentially due to the way that 3D applications, used in the context of a level editor, work with 'flat planes' as opposed to level editing tools use of 'volumes'. This effects the outcome of the export process and can have a detrimental effect on the resulting map if not mindful of the following points;

• Brushes are created as 'thin skin' volumes ^

  Mesh polygons are converted and exported in one of two ways;

  • An enclosed polygon cube (similar to the cube in Blenders default scene) is exported as a brush that's a solid volume.

  • An 'open' primitive, single or collection of polygons are exported as 'panels' - removing the top and bottom from a cube, for example, results in the remaining sides being exported as mitred panels.

  Being able to build as much geometry as possible as 'closed' shapes ('sealed') would be ideal, but it's not always possible, especially if a levels architecture is relatively complex. The only option available in that case is to build the models using 'open' meshes and polygon planes.

  Faces, polygons and 'open' shapes cause the most problems because in essence the way the script works is that it looks at a face and extrudes it backwards along the normal to create a 'volume', the depth of which is limited; in effect it's producing something commonly known as a "thin skin".

  Generally speaking, if the converted model is left as is and 'structural' in nature, this 'skin' or 'shallow' brush building procedure results in poorly 'optimised' levels that have a tendency to cause compile problems; notwithstanding map 'leaks' due to gaps between brush volumes - brush accuracy problems occur where the process hasn't quite been able to create 'good' geometry (it's noted here that this may not necessarily be the problem of the script but the accuracy of the brush data format itself).

  
  Issues relating to brush accuracy, which cause holes, gaps and leaks in compiled maps

  The fix for this is to convert as much brushwork into "Detail" flagged volumes as is possible (see below).

  Additionally it's worth noting that the 'thickness value' does not necessarily correspond to the Radiants default grid settings, which will likely cause issues in of itself.

• Brush joints are mitred ^

  When exporting objects that are composed largely of flat faces/planes and 'open' primitives (a box without a top and bottom for example), due to the the way the export process creates volumes from flat polygon planes, it tends to try and mitre joints where brushes meet. However, it does so using a 'best fit' approach to mitring joints to 45° angles as much as possible rather than butting the brush volumes up to one another flat face to face - as most of the unused faces are covered in caulk it's not specifically necessary to mitre them where they join.

  
  Exported brushwork is mitred at corners

  This causes a primary problem based on the way the brushes are written; if one is moved or manipulated there is a good change it will break or 'collapse' due to the lack of precision afforded to the exported brushwork; the snap to grid option available during export from Blender may fix this to a point in respect to polygon edges that were already 'snapped', anything else may show up as a misaligned edge or face in Radiant which will require further work to 'fix'.

  There are technical reasons 'for' and 'against' mitring, however, from a practical point of view it can become time consuming to 'treat' edges in such a way that every volume is mitred to its immediate neighbours.

• Maps are exported relative to being 'structural' brushwork ^

  Due to the way the brushes are formed as part of the model to map process it means a map contains many, many more 'solid' brushes than is necessary for a functioning level. Now because this output is "Structural" in nature it means that brushes will block VIS(ibility), make 'cuts' in the BSP file to create 'portals' and be of a file size relative to the data that that generates (BSP needs to be under 2MB usage).

  Optimised levels, on the other hand, use as little "structural" brushwork as possible.

  It's vitally important to understand this primary point because ignoring it will result in a map that won't compile or run in game, and more importantly, means rebuilding copious amounts of the level to correct problems that arise as a result of ignoring this particular point.

  A partial fix for this issue is to convert the exported brushes to 'Detail' flagged volumes (see below).

• Materials, textures and orphaned shaders ^

  The initial texturing that's assigned to brush faces is determined by the textures applied to the mesh in Blender - the name given to a shader in Radiant is the same the the actual file name of the image UVW mapped to the mesh. So areas (or whole maps) that use more than one texture - for example, a wall that has both a 'brick' and 'trim' texture UVWmapped to it - would have two distinct shaders created for each texture respectively, named the same as the applied images.

  
  Shader names in Radiant are taken from image file names of textures applied to models

  Additionally, unlike creating meshes that are exported to various game-ready model formats, when exporting a map from Blender it will use and process 'multimaterials' correctly; in other words, a model does not need to be broken down into sub-objects based on material/texture assignment.

  Bear in mind also that if texture paths aren't correct as a model is being worked on in Blender, opening the resulting map in Radiant will show the 'orphaned' red and black checker editor image associated with missing or broken shaders. To remedy this it's best to work on the Blender file with a 'relative' folder structure that replicates the same hierarchy of the game being edited, for example;

  • \Root project folder\ - Blender files are stored in here
    • \textures\ - texture assets reference from here
    • \models\ - texture assets also referenced from here (where necessary)

    • \maps\ - exported map can be saved here

  Failing that using Radiants "find and replace" tool on these erronous texture/shader assignment issues, it's possible to sort out the problem relatively quickly (as it can with any shader assignment work).

• UVW mapping models in relation to exporting as maps ^

  Whilst models can have very complex UVW maps applied to them, brushes can't, everything is 'planar' mapped - that is, 'flat projection' UVW mapping surfaces. So by default, the exporting of a model to a map will process face data largely ignoring any 'complex' UVW mapping that is applied to a mesh and simply 'planar map' all the faces it comes across.

  There are limitations regarding what can be done with textures 'mapped' to brushes in this way, but most adjustments can be done using Radiants surface tools ("Shift+S" and "S").

• Export quads and not triangles ^

  Because brushes are 'volumes' an unedited brush object is essentially the equivalent of a solid polygonal 'cube' (more akin to a block of stone, than an empty box). What this means is that they are largely composed of 'quadratic' polygons ('quads' for short) - faces that are composed of four corner vertexes - that tend to hold that shape whilst being edited and manipulated in Radiant. Knowing this effects the prepping of the model before export;

  All the faces need to be left as quads as much as possible in order for brush integrity to remain optimal.

  
  Flat shaded view in EDIT mode showing the polygons as 'quads' that make up the mesh.
  
  Similar view in GTKRadiant of the Blender shot immediately above, 'quad' based brush volumes selected

  The main reason for this, aside from the way Radiant works with brush volumes, is that breaking a model down into triangles ('tris') results in a lot of 'accuracy errors' in brushes due to the way the script tries to 45° mitre the shapes and acute angles present in a triangulated mesh - remember that all adjoining brushes are mitred, this is carried out to the 'enth' degree and applied to all converted polygons which leads to the problem described in the following.

  So, although the 'front' face of a brush may be aligned correctly to its immediate neighbour, the back and sides may not - if a brush is triangular and at an 'off grid' (noaxial) angle it more than likely will result in 'spiked' brushwork that have extended edges, faces, or points poking out beyond the expected bounds of the brush and potentially into 'good' space inside the level (see image below).

  
  'Spiked' brushes poking out into 'good' space as a result of the exporter mitring all adjoining edges to other brushes
  

  Leaving a mesh with the polygons intact as quads avoids this problem to a great extent.

• Scaling the model to the right size ^

  When working on a level in Blender there are basically two ways to go about it;

  1. Work at Blenders default scale

  2. Use a reference object to work to scale (at actual size)

  If neither of these is done then it means a process of trail and error will be necessary in order to get the scale correct. To avoid the problems associated with doing that, it's preferable to use reference objects and work relative to the size of those - so long as "Apply Scale and Rotation" is not used on re-sized objects, it should be relatively straightforward to work out what "Scale" setting should be used on export to get sizing correct.

Brushes as 'detail' flagged volumes ^

As mentioned above, a number of problems associated with using a map converted from a model in this way can be resolved by the use of 'detail' brushes. This is where brush volumes are 'flagged' (marked) as non-structural, which in turn means they have no effect on visibility in the map - they don't block the engines view of what can be rendered based on the players POV. In other words, standing behind a wall that's been 'detail' flagged won't prevent what's behind it from being rendered even though the player can't see it.

It's important to point out here that flagging brushes as 'detail' does not in of itself solve the problem of messy brushwork, all it does is prevents the excesses associated with compiling a level built ostensibly from the type of brushwork generated by the ('open' mesh) model to map conversion process, namely as that relates to BSP splits and portals.

HOW TO : flag brushes as 'detail'

Select a brush or collection of brushes by Shift+LMB or drawing a brush volume over a selection and using the "Select > Select Inside" menu option. Once objects are selected, RMB click anywhere in the 2D view and from the pop-up menu select "Make Detail"; nothing will happen, but the selected brushes will be now be marked as 'detail'.

To test this use Ctrl+D (or "View > Filter > Details") to toggle between "show / hide detail" of any brush volume flagged as detail; if the volume is marked 'detail' it will disappear from view.

The main reasons for going to all this trouble converting brushes from 'structural' to 'detail' volumes boils down to two main issues; BSP file size and bot navigation issues.

'Detail' flagging brushes, BSP file size & bot navigation ^

The compiling of a map is something called a 'recursive' process, i.e. space is cut and then check, then cut again and further checked until a point is reached where the compiler is mathematically satisfied there are no more divisions of space required. Each time one of these divisions is made in the BSP it uses up part of the allotted 2MB data limit - the more divisions, the more data is used - until the process runs out memory and displays one of the various MAX_MAP_ errors as a result.

So, the more cuts the geometry causes in the BSP, the larger the file size.

In addition to this, these 'cuts', or 'portals' as they're correctly called, are used during the calculation of bot navigation and, as with everything to do with level design, the more complex the structure the more difficult it is for the game to use if it's not 'processed' or 'prepped' correctly beforehand.

A 'Portal' is in effect 'space' inside the map that's created as a result of the structural splits caused by brushwork. For example, if a simple box were compiled it would contain one 'space'. Now add a wall to divide the box into two with a gap for a door and the result is a box with three 'spaces' in it - one either side of the wall and one in the gap where the doorway is (the same thickness as the dividing wall).

Now the problem with using a converted model that's made from 'open' meshes 'as is' in this context, is that they tend to cause a lot of splits in the BSP (as mentioned above) which result in an equally excessive number of portals; these can sometimes be clustered together so that many small portal spaces are contained in a larger given area; or they can be at very odd and peculiar angles due to the way splits are generated along planes - imagine extending an edge of a curve until it hits something - it will more than likely slice through other areas and as a result create oddly shaped portal spaces.

The net result of having too many, small or oddly sized/shaped portals is poor bot navigation (amongst other things).

So, to minimise this problem a map needs to have as few as possible and they need to be 'axial' in nature, i.e. be at 90° angles to each other where-ever possible. To do this the converted model needs to be extensively 'detail' flagged.

It's worth pointing out here that there are other reasons and issues "why" that can arise from BSP splits and portals but the two mentioned above are the most common problems that result from poor brushwork during level construction, regardless of the method used to generate said brushwork.

Caulk hull building ^

In order to make the best use of detail flagged brushwork it needs to sit inside a 'hull' made from basic blocks and shapes covered in 'caulk'; this is commonly referred to as the "caulk hull". Whereas detail brushes don't effect visibility or the BSP, a caulk hull does because the brush volumes are in their default 'structural' state - it's this hull that is used by the compile process to determine what can be seen from any given point of view.

Building a caulk hull is best done within GTKRadiant (see below).

Depending on the architectural structure of the converted model the caulk hull needs to be as simple as possible but at the same time leave as little 'dead space' in the map - these are areas caused by gaps between the outer caulk hull walls and the inner contained detail brushes. Although there are ways to deal with specific problems that arise from such areas - such as using various 'clip' volumes, it's always best to try and remove them at this point without causing too many BSP splits - remember, structural brushes cut into the BSP so keeping the number of exposed edges to a minimum is ideal.

There are different schools of thought on exactly how brushes are joined when doing this - 'mitred' or 'butted' joints, but suffice to say, ideally the 'inside' of the hull should create as few splits in the BSP as possible, but be dependant on the architecture within given areas (see the note above regarding 'portals'). For instance in the image below using a simple box would suffice in this instance so the raised areas and 'pillars' aren't (absolutely) necessary; they are placed in the example to indicate that you can do so if/where required.

The trick is to keep the hull as simple as possible without compromising visibility (what is drawn by the engine).

General level editing considerations ^

Some further considerations to keep in mind when building a model to be exported out as a map.

• Caulk hull ^

  Although, as discussed above the caulk hull is best built inside the Radiant editing tools, it is possible to build it as a model. However, in doing so the following needs to be kept in mind - caulk hulls tend to work best as solid blocks and volumes, so, only 'closed' cubes and 'solid' primitive shapes should be used to surround a model when building a caulk hull in Blender; using 'open' meshes and polygons won't produce the brush volumes required for caulk hulls, i.e. the process would be looking at the hull as individual (extruded) faces rather than solid blocks which would need to be replaced or edited so that only solid volumes remained - remember that 'dead space' is bad as it may create splits and portals that potentially could cause various problems.

  When building the hull as a model it's important that it's overal structure adhears to and corresponds to both the grid in Blender and the grid in Radiant; this means making sure that Blenders grid settings are correctly ser up.

• Blenders to Radiant grid spacing ^

  Related to the above, in order to maintain a 1:1 relationship between the grid in Blender and Radiant it's best to work within Blender at scale and using grid settings that correspond to Radiants defaults.

  HOW TO : grid setting in Blender

  In Blender, open the View Properties panel - "View > View Properties" and change "Spacing" to "8", "Divisions" to "8" and LMB click drag "Clip End:..." as far as it will go ("80000.00").

  This is also true of any modelling carried out that is intended for use in a game. For more details see the prepping models tutorial here.

• Snapped to the grid ^

  When modelling in Blender with the intention of exporting the results out as a map it's important to make sure, as much as is possible, that work is carried out whilst snapped to the grid. In other words, major structures should be made and manipulated so that they follow Blenders grid.

  The specific reason for this is related to the accuracy that's possible from the *.map format itself, and the way the Radiant level editor treats objects, faces and edges that are 'offgrid' or 'nonaxial' (at odd angles to the grid); in effect Radiant depends largely on objects being sat on the grid to properly maintain an objects integrity.

• Texturing ^

  Although the export process ignores 'complex' UVW mapping in favour of a more simple 'planar' UVW map, it's best to do some UVW unwrapping and texture/material assignment as this is where the scripts gets shader assignments from. The upside of this it that despite the liberal appearance of the 'missing' shader in such instances, there will at least be correct shader application on brushwork making the job of texture adjustments and/or find and replace much less time consuming to fix.

• Lights and game entities ^

  Exporting a model to the map format does export lights, however, beyond positional (and colour) information little else is carried over which means that lights will need further editing once in Radiant.

  This is also true of other game specific entities such as player_start entities, weapon markers, ammo boxes and so on, so it's best to use Blender to build the structure of the level and leave entity set-up to Radiant. Primitive objects can be used in Blender as place-holder position markers, but they will simply be exported as brush geometry and have to be removed once in Radiant (brush geometry can't for those types of entities).

Conclusions ^

As with level design generally a certain amount of preplanning is ideal, especially when working this way so as to ensure that as few problems occur as possible; most issues that arise usually relate to scale and grid problems - brushwork being too small/large and gaps/overlaps as a result of incomplete or approximate conversion of the models polygon faces into brush volumes.

It's also worth noting that the *.map format is relative cross platform from the point of view of using the same source model to create levels in more than one game engine; the same model can be exported out to a *.map and used in Quake 3, Doom 3, Quake 4, Prey and Quake Wars as they all fundamentally use the same data structure and/or can read in Quake 3 map data and 'convert' that into the appropriate format for use (there are some organisation differences between map generations associated with the different game engine generations).

As this tutorial has shown, it is more than possible to make a level in Blender 3D as a model and export that out as a map. And although the use of a 3D modelling application means more physical flexibility, that is still best done using the same, similar or approximate considerations that would be applicable when building the same map with the traditional level editing tools, GTKRadiant (and QeRadiant).

FOOTNOTE: converting models to maps from 3DS Max and other 3D applications ^

It's probably dawned on none Blender users reading this tutorial that yes, it should be possible to use this process as a go-between to convert a model made in 3DS Max (or any 3rd party 3D application - Maya, XSi, Lightwave and so on) into a map; all that's required is that the source model be exported out to a format that Blender can import intact. Once there some tidying up may be required but so long as everything imported correctly Blender should then be able to export the model back out and directly into the *.map format.