[back]How to.. Converting maps into models

Contents

• What's this all about?
• 'Notes' to note
• Structural brushwork and 'breaking' models
• Object centre and bounding box rendering
• POO based object rotation
• Prepping the brushwork
• Map prepping checklist
• Using Q3Map2 Toolz to convert maps to models
• Quick set-up notes
• Overview of Q3map2Tools
• Converting a *.map into a *.bsp
• Converting a map with curves to a *.bsp
• Converting a *.bsp into a *.ase model
• Importing the ase into a modelling application

What's this all about? ^

The use of models is normally because certain objects are too complex to create using brushwork or patch meshes, they do however serve additional purposes;

• Allow 'smooth grouping' on world objects - this effects the way lighting 'behaves' on surfaces, by default brushwork doesn't have smooth groups.

• Reduced polycount compared to patch meshes - Patch meshes in the Q3 engine have a fixed row/column relationship which means the more complex the curve the more polygons are needed to describe that curve (thankfully Doom 3 engine editing allows the manipulation of the row/column relationship).

• 'Optimises' the compiled BSP.

In other words, sometimes using brushes just doesn't look right so you need to find a way to represent what you're trying to do using other means; this is where models come into play.

'Notes' to note ^

Before going any further one important note to keep in mind;

The position of brushwork relative to the editors (Radiant and GTK Ratiant) 0,0,0 grid centre is important, this will eventually be the 'Point Of Origin' ('POO') for the model, around which the object is rotated and manipulated in both Radiant and which ever 3D modelling application is used to edit the mesh. It's essential to keep this in mind before exporting/converting the brushwork as per below.

There are a number of 'technical' reasons for this (see next sub headings for further details on each 'reason');

• Models 'break' if the POO is buried in (structural) brushwork [>].

• Models are rendered based on the POO position in relation to the objects overall bounding box limits [>].

• Models are rotated, moved and position based on the POO [>].

Structural brushwork and 'breaking' models ^

Models and entities 'break' if their point of origin is buried in structure brushwork (brushes that are seen as being 'solid' by the compile process - they seal the map from the void) which results in the map returning a 'leak' error during the compile process.

This means that when prepping brushwork for conversion you need to over compensate for the relative position of the POO against it's eventual use as a model when it's brought back in to the editor.

The brushwork platform shown in the images below has been aligned to GTK Radiants 0,0,0 grid centre to allow plenty of room for the support struts to be buried deep into brushwork without blocking or otherwise interfering with the models point of origin; as an example, a rock face (which the model used in this tutorial was originally intended for) doesn't usually have a flat surface. This means the original brushwork has to be made in such a way that any 'extremes' have to compensate for placement over a deep cut or around a long curved wall section.

In other words, the support beams had to be made longer than normal so they could be embedded into brushwork comfortably without burying the point of origin of the model, as opposed to floating around in mid air because they're not long enough to reach the wall and you don't want to break the model by burring the origin point.

Object centre and bounding box rendering ^

Game engines tend to process and render models on a 'per object' basis and not a 'per polygon'. 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 being pulled into the game and processed; the 'area' or 'volume' the model occupies is often referred to as it's 'bounding box', so anything contained in that box will be rendered if any part of it is seen.

To remedy this, large models need to be broken down into smaller more manageable and render friendly chunks, which then fit back together in the game editor - just like a jigsaw - allowing the game to process and render smaller chunks of data, making it faster and reducing something called 'overdraw' (where the engine is rendering polygons the player can't see).

Design note : The downside to doing this is that you inadvertently create 'forced' smooth groupings which often result in noticeable hard lines, edges and/or shadow transitions in game where two or more edges meet.

In having to do this it does mean you need to be mindful that each section actually aligns itself properly in the editor and the 3D application you're using, each section needs to be re-centred to the 0,0,0 axis point before being exported back out for use in game.

Design note : Make sure you use snap to grid in your 3D application when shifting objects around like this, otherwise it's impossible to correctly align modelled objects in the editor.

You can do the re-centring in the initial map that needs converting by breaking the brushwork into sections, re-centring to the editors centre point and then exporting each unit out for further work. The advantage is that each exported section is 'gridlocked' and will fit perfectly together with it's neighbour.

Or you can export the whole map and then section it in your 3D application. The advantage of the this means that 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.

POO based object rotation ^

An object rotates around the point of origin so having that placed in an odd position may adversely effect how the model is manipulated, tiled and connected with other model sections. Where ever possible it's best to try and centre the POO at the objects centre of mass relative to the other sections or models it needs to fit together with. Make sure snap to grid is 'on' in your 3D app.

Preparing brushwork for conversion to ASE

Prepping the brushwork ^

The basic principle of converting maps to models is to compile them as you would any other map and then 'convert' the resulting BSP to a model format; *.ASE in this instance.

Design note : If you're using the editor that comes with Doom 3 powered games it's worth pointing out that you can export brushwork selections straight out into OBJ formatted models. The downside is that all faces of selected brushwork get exported rather than just the ones that are textured (and that you need), as is the case with ASE models converted from BSP files using Q3map2.

Once you've selected, copied or created the initial brushwork that needs to be converted into a model it should be surrounded by a caulk 'hull' box. The box should encase the object; top, bottom and each North, South, East, West facing side.

Make sure to also caulk all unnecessary faces of the brushwork object otherwise they will be present after the conversion and will need to be manually removed from the mesh in a 3D application.

It's important that there are no gaps of any kind because the map will be compiled, gaps will result in the same type of 'leak' as you'd get normally when compiling a map to run in game.

Design note : If you're grabbing a selection made from a previously made map, then once you copy it over to a new map, make sure you strip out any game entities and that you 'break' brush based entities back into their constituent parts (the exception are 'func_group' based brush entities); although it's more than likely they will simply be compiled into the final ASE file, it's best to remove them to reduce the possibility of errors cropping up during the conversion process (helping with bug tracking in the process).

If you've used 'detail' flagged brushwork it can be left as is because the surface flag has no effect on the compilation of the brushwork when converting maps to models.

Patch mesh objects undergo 'special' treatment during compile. See below.

The box then needs to have a info_player_start placed inside it, it doesn't matter where so long as it doesn't intersect or get in the way of any brushwork or the caulk hull - which would cause a 'leak' (due to a broken entity).

As mentioned above in the 'Notes' to note' section it's important at this stage of the process to make sure the brushwork selection is centred on the editors 0,0,0 grid point relative to the eventual function of the object. If it needs to be buried into any brushwork, in the editor make sure that you adjust the objects to allow/compensate for this; a lamppost would have it's POO (positioned in Radiant) approximately halfway up the main pole to allow the bottom to be safely buried without problems.

Map prepping checklist ^

• Centre brushwork appropriate to the intended use of the model

• Remove all game related entities except info_player_start

• Texture only the faces you want converted

• Caulk all unseen and unwanted faces

• Use info_player_start entity only, not another player or ai spawn marker

• Break brush based entities back into normal brushwork

• Place a caulk box around selection

• Make sure there are no gaps or leaks

Once this has all been done just (version) save the file (if you've got more than one version) to the defaults 'maps' folder for ease of use later.

Using Q3map2Tools

Using Q3Map2Tools to convert maps to models ^

The following steps can be done using a BAT file, that's for hardQore mappers and not covered here. For the rest of us, using some sort of 'front end' that connects to the various options of Q3Map2 is preferable; in this case that's Q3Map2Tools.

Design note : Converting map sections to models like this does not work with any 'default' version of Q3map; in other words, the versions of the BSP map compiler often included with official editing tools is not capable of doing this type of map to model conversion. For this to work correctly you need to use the much updated and improved Q3map2

What's actually being done in this tutorial is the compiling of a map file into a BSP in a similar way as would be done if it were for any Quake 3 powered game which is usually a three part process;

• BSP - the map is 'blocked out' and broken down into basic divisions.

• VIS - the Visibility of the map is calculated; what can be seen from where.

• LIGHT - the lighting of the map is calculated.

However for this map to model conversion process only the initial BSP stage is required.

Quick set-up notes ^

If this is the first time you've used Q3Map2Tools then when it opens you'll be asked to provide some information regarding the whereabouts of the *.map compiler - Q3map2 (see 'Design note' above); simply browse to the location it's installed and 'OK' the information to add it to the list.

Design note : Q3Map2Tools allows you to use a number of different versions of the compiler so providing you add the location details when asked you shouldn't have any problems doing so.

Overview of Q3map2Tools ^

When Q3Map2Tools opens it will present you with something similar to the image below. In essence the application is split into two sections; a map list section with all the *.map files sitting in your default maps folder listed; only one can be selected at any given time. And a compile options section with various options available for compiling and debugging maps.

Once a selection is made from the list[1], various compile options are set[2] and the 'Run BSP' button clicked[3] to output a compiled *.BSP file which can then be run in game.

Converting a *.map into a *.bsp ^

As mentioned in the overview above, before a map can be converted to an ASE model it first has to be compiled to a *.BSP file.

By default the 'Selected File' panel will show 'MapFiles (*.map)' as shown above, this is a listing of all the valid *.map files the tool finds sitting the default "/maps/" folder;

Design note : You can't browse to files so they either need to be in the default maps folder (/base/maps/ in the case of Quake 3) or located in a 'mod' folder (mymod/maps/ in case of a custom modification).

• Select the file from the list

• Select (click) 'Normal' from the BSP Options panel

• Click 'Run BSP'

A BSP file will the be made from the map and saved back into to the same 'map' folder the file came from.

Design note : There are a number of options that can be activated for this step of the process (by selecting a 'Custom' compile[2]) but they're not necessarily required for general map2bsp compiles.

Converting a map with curves to a *.bsp ^

If the brushwork object being compiled has or is composed of patch meshes or curves then a 'Custom' map2bsp compile is required before going on to the next step (this is because meshes tend to be treated slightly differently to brushes because of what they are);

• Select the map from the list.

• Select 'Custom' from the BSP Options panel (which should 'activate' the options listed below, previously grey out)

• Select -meta and -patchmeta

• Press the Run BSP button

This will save an 'optimised' file into the maps folder as above. Once the *.BSP file is created the next step can be started.

Converting *.bsp into an *.ase model ^

From the drop down at the top of the 'Selected Files' window select the 'BSPFiles (*.bsp)' option. This will show the map just compiled as well as any other previously compiled map files converted to BSP's. Do the following;

• Select the correct *.BSP file[1]

• Move over to the BSP options on the right[2] and from there select the 'Custom'[2] radio button option (click the mouse in there) - by default 'none' is usually active - doing this will 'activate' the various compile options below[3]

• From these options find a parameter marked as '-convert' and select that[3]

• Then in the text field to the right of that option type 'ase'

• Once that's been done click the 'Run BSP' button[4] to process the BSP file and convert it into an ASE mesh.

This will then output the converted BSP as an ASE saving it to the 'maps' folder.

Make sure not to use the 'Build' button at the bottom of the application as that will try to do a full compile on the BSP and possibly error out.

What should happen at the end of this is the production of an ASE mesh that's composed of the brush faces that were actually textured; anything covered in caulk is ignored by the process, including the caulk hull box which encased the brushwork (as well as the player_start entity). This means the end result is much 'cleaner' object for editing in a 3D application.

Getting the converted ASE into a 3D application

Importing into a 3D application ^

So long as your 3D modeller of choice can import ASE models directly (native support or by third party scripts or tools) there shouldn't be any problems bringing the mesh in 'as is'. If not, an extra step will be needed requiring the object to be converted again into a format that can be used; Q3map2 only converts brushwork to ASE models.

There are a couple of points that need to be kept in mind when bringing in converted models of this nature - in essence the only useful data that's brought in like this is the vertex and polygon face information, UVWs are kept but they're not really useful from the point of a model;

• 'Planar' UVW unwrapped

  The UVW mapping applied to the faces of what were brushes is optimised for brush objects and not models; essentially a 'flat', 'face on' projection is used - brushes are UVWmapped as individual units and as such it's often the case that although a texture may visually tile correctly over a group of faces it's not necessarily the case that the actual mapped UVW's will be doing the same thing and form a contiguous selection of UVW'd polygons.

• Triangulated mesh

Because the compile process by default breaks brush data down into triangular polygons it means that converted models produced via this method are imported in the same state; they are composed of triangles rather than quadrangles (which is preferable for modelling).

• Un-merged vertex points

Brush faces by default aren't merged together to form a contiguous mesh, this means that each triangular polygon and it's three corner vertices are separate objects from their immediate neighbours.

• Missing textures

More often than not a mesh, although UVWmapped, will import into a 3D program without textures because of the way texture and shader paths are written to the ase file.

• Individual faces

As with un-merged vertices above, by default triangular polygon faces are not connected together, instead they are individual objects and need reconnecting in your 3D application.

• Models relative position

As mentioned above, a models position in a 3D application's viewport is relative to where it's placed in Radiant before exporting, maps sections can be built and exported in situ where required and recentred in the 3D app before re-export back out to ASE.

Most 3D applications will have some method of merging vertices together and converting triangular faces into quadratic polygons, it's a good idea to do this where available to ease the modelling process.

Once this has been done the mesh can be edited and then re-exported to ase once work has finished (covered here).