Resources

In this section some of the main points, concepts and more complex issues inherent to the export process are discussed, what that means when making models for game modding or development and common problems associated with the export process and their fixes and/or solutions.

N.B. the process explained below can also be used to export (static map object) models from Blender 3D to other formats, not just ASE, the principles are generally the same irrespective of model format being used.

A typical model scenario for export is of an object composed of several sections and/or has several materials applied to it; essentially an item with a number of 'sub' sections. In the previous chapter it was recommended that objects of this nature be 'unique' in terms of their "dataBlock" usage inside Blender, or in other words this would mean there being, to continue using of the corridor section as a production example in this instance, five separate and individual "Object", "Material", "Texture" and "Image" dataBlocks and physical asset references (shown below). There are three general reasons for this;

Version loading/saving.

Object Hierarchy.

Bug tracking.

Version loading/saving ("1") means there is always a 'base' version from which to work so any changes or mistakes can be reverted, quickly and easily. As game engine technology determines final output, scene organisation and Object Hierarchy ("2") therein needs to take into account whether 'multi-materials', 'multiple materials', 'sub-objects' and/or 'single object' meshes are to be used. It's important to understand the distinctions between each type of hierarchical set-up because not all game engines use the same data structure; getting this wrong is usually the reason models don't work as expected. Separated meshes allow for easier bug tracking ("3") issues if a scenes initial condition is 'clean' and in a 'knowable' state. In other words there shouldn't be any second-guessing as to the presence of any fundamental errors; it shouldn't be a 'guess' for example, whether-or-not a mesh has improper material assignments, it should be 'known' that there aren't when looking at meshes pre-error.

The individual elements that go into the making of a typical game object; each item is a separate 'object' with it's own material and texture.

Whilst the above points are not required for the proper export of models from Blender, they should at least be considered the backbone of "good practice" when working so the amount of time, effort and resources used for development are kept to a minimum.

As briefly mentioned above, the primary concern for the proper export of models is to make sure that the internal structure of the mesh is set up correctly relative to the game engine or environment being used. What this means is that if final output needs to be composed of multiple objects and multiple materials it has to have a hierarchical structure similar to that shown in the column on the left below. Whereas, if output needs to be composed of a single object with a single multi-material, the hierarchical structure would need to be similar to that shown in the column on the right below. This isn't a question of "which is best", but rather one of "what's appropriate"; a sub-object structure isn't necessarily better than a single object, however, neither will work properly when used in an wrong type of editing environment.

Sub-Objects with multiple materials

mesh sub-object (hull)

material (hull)

texture (hull.tga)

mesh sub-object (collision)

material (collision)

texture (collision.tga)

mesh sub-object (walls)

material (walls)

texture (walls.tga)

mesh sub-object (floor)

material (floor)

texture (floor.tga)

mesh sub-object (sky)

material (sky)

texture (sky.tga)

Single object mesh with multi-material

mesh sub-object (joined objects)

material (hull)

texture (hull.tga)

material (collision)

texture (collision.tga)

material (walls)

texture (walls.tga)

material (floor)

texture (floor.tga)

material (sky)

texture (sky.tga)

Object hierarchy set up so that the final output is composed of multiple objects and materials. This produces several sub-object meshes inside the ASE with associated individual materials assigned

A collapsed object where all the separate elements are joined together to form a single mesh which then has several materials. This results in an ASE with a single mesh and several sub-materials

The "hierarchical structure" then, determines the 'state' in which a model is to be exported. If a single object is required then individual meshes need to be joined together using "Ctrl+J", or "Object » Join" (from the scene Header menu). This 'collapses' the internal data-structure of both the individual mesh objects and the individual material assignments so the end result is a single mesh with what then becomes a "sub-material" or "multi-material" assignment. On the other hand, if the ASE model needs to contain a series of 'sub-objects', that is, the model needs to be composed of individual sub-mesh elements, then objects should be selected as a group, but NOT joined for export, resulting in several "GEOM_OBJECTS" 'inside' the ASE, each with it's own associated material. In both instances the resulting ASE model will typically reflect the hierarchical structure present in Blender before items are selected and exported (as shown by the different "OOPS" schematic panels per model 'type' shown below).

Collapsing a mesh and materials so output is a single object with a number of sub-materials distinguishing elements

Exporting a model so the final output use sub-objects and separate materials assignments (per sub-mesh element)

In addition to the two main object hierarchies mentioned above, a third exists whereby models are composed of a single mesh with a single material. This is typical of 'unique' models which use tailor-made textures, or in situations where technologies can only read 'simple' mesh data. For complex model exporting this means one of two things; either the entire hierarchy is collapsed and materials, textures and images are mapped to a single reference (one single texture image for the entire model), or each sub-object is exported as an individual object in it's own right with its own material reference.

In practice, for a model like the corridor section being used throughout this tutorial, this means the former set up (single object, single material) results in an object that's 'whole' when brought into the game editing environment (the model is loaded in its entirety, all elements and material are part of the same mesh); the latter means the corridor section has to be reconstructed from separate parts (each part is a section of the original model that has to be put back together with its brethren in order for the model to be usable).

Models used in this type of situation, that have been (previously) 'joined', need to be broken into a series of individual objects. Make a selection based on single material assignments in Edit mode, press "P", then select "Separate" from the menu (or use "Mesh » Vertices » Separate"). Note that particular attention needs to be paid to material assignments and object Origins (see below).

Collapsing both the sub-objects and sub-materials into a single mesh assigned a single material, in instances such as these it usually means the entire object is mapped to a single unique texture image, the OOPS view highlights this set up (although not shown on the model itself - as each 'texture' would in fact be a separate mapped area of the same image)

As explained above, collapsing a mesh affects the structural hierarchy of an object in terms of its being made from a single mesh or collection of sub meshes. This is also true of an objects "Material Hierarchy" and whether that means using "multi-materials" or "multiple materials". As with collapsing meshes it's important to understand the distinction between "multi" and "multiple", they are NOT the same thing, and this too is another typical reason why models appear missing, misapplied, partially or completely devoid of textures in game; it's vital to make sure that materials are collapsed and assigned correctly - care must be taken to ensure the removal of any dead or unused references.

The "OOPS" schematic is a useful tool in this regard as 'junk' materials don't always display in the viewport, i.e. they're not always visible on a mesh so the 'OOPS' schematic is helpful in showing the assignment to objects of any associated but unwanted dataBlocks (shown below). To delete dead material references using the 'OOPS' schematic RMB select an entry (click the "+" to expand available information) then click "Unlink" to remove the dataBlock reference being used. Else delete material references using the "Material" and "Texture" properties panels.

Make sure to clean 'dead' or 'junk' materials from individual meshes. 1) is the actual material that should be present on the mesh. 2) is a ''dead' material reference left in place as a result of a previous connection to another object. This should be deleted to prevent problems. 3) only a single material should be present per sub-mesh element (before being joined)

An objects position on Blenders grid is important as it relates directly to how the resulting model appears and is used in game. For example, tiled assets tend to use different criteria to determine placement compared to non-tiled assets that need to be buried in other level geometry. What's being specifically referenced here is the "Origin" point of a model, the small sphere the manipulator 'widget' focuses on by default when meshes are selected in Blender, the position of this is relative to the object and how its to be subsequently used. This means further considering a number of criteria per object;

physical size as that pertains to its 'bounding box'.

position relative to Blenders "0,0,0" grid centre.

the rotation relative to it being 'on-grid' and 'axial'.

the location of the objects 'Origin' point.

Depending on what a model is being used for it's not necessarily going to be arbitrarily sized, 'world' objects in particular generally conform to the same 'power of two' rule as textures as these types of assets need to use sizes that makes sense to the game, especially if they're to be tiled and fit together like building-blocks. The "Dimensions"[5] of the object, as shown in 'view' "Properties" ("N"), relate to the objects overall 'volume' or 'bounding box', important for games as modelled assets tend to be processed based on their volume rather than their physical structure/characteristics.

'Fix' an object or objects position relative to Blenders grid before export to ASE. Data to set in place includes "Location", "Position" and "Scale"

Additionally, other 'position' related data needs to be set via the "Apply" options before export to ensure proper placement of models when used. Select an object, press "Ctrl+A", or use the Header menu option, "Object » Apply" and select in turn "Location", "Rotation" and "Scale", ensuring that each is set to "0.000", "0º", and "1.000" on each "X", "Y" and "Z" axis respectively. This fixes 'size' and 'position' related data so the models gets exported 'as is'.

Both "Apply" and "Set Origin" should be done after objects are correctly positioned on Blenders grid, usually through the use of the 3D cursor - by using various "Snap" options, via "Shift+S" or "Object » Snap » Cursor to Selected", to place the cursor at a previously set position. Or using "3D Cursor Location" data[4] (above) to fix the cursor position, then snapping the origin point to that using "Shift+Ctrl+Alt+C".

Make sure to correctly set the position of the Origin point of objects before export to ensure proper position of the ASE model in game

Although "mesh smoothing" ("smooth groups") can be placed manually or by using some form of automated tool or processes in Blender, they produce the same end result by way of splitting the coincidental vertices shared between two or more polygons, breaking a 'link' between them. Where this occurs surfaces cease being 'contiguous' ('continuous'), so shading data - which is what mesh smoothing is - doesn't get passed to, or averaged over, the separated faces. This results in an 'hard' edge at the split. Whilst correctly setting up mesh smoothing is a topic in of itself, but suffice to say here that to force split faces and create mesh smoothing manually, make a selection (in Edit mode) then use "Y", or "Mesh » Vertices » Split" from the Header menu, to split elements apart. Alternatively from the "Properties" panel use an "Edge Split" modifier from the "Modifiers" list on the mesh in Object mode, then define the splits using "Mark Seam" from the "Edges" menu ("Ctrl+E" select "Mark Seam"). On export be sure to 'apply' the modifier (by clicking "Apply" from the stack, or, enable any "Apply Modifiers" options during export where available) so the mesh exports with the splits in place (not necessary for manually placed splits).

Because of the way game engines work, polygons ('quads') need to be broken down into their core elements, that is "triangles" and "vertices" as these can be rendered much more efficiently than 'quads' (which require an extra 'step' of processing - "vertex » triangle » quad" instead of just "vertex » triangle"). In Blender 2.5 the process by which this can be done is called "tessellation" or "triangulation". In Edit mode the elements to be processed need to be selected as faces, edges or vertices - "Selection Mode" isn't critical here as triangulation works any 'mode' so long as a given selection constitutes a 'whole' polygon - and then the tool applied to the mesh using "Ctrl+T" or "Mesh » Faces » Quads to Tris". This will break everything in to the necessary triangles (see below). Typically this should be done to all object before export to ASE.

Triangulating a mesh using "Ctrl+T". Modelling should be carried out using quadratic polygons which are broken down into their triangular parts before export

Although a tessellated mesh doesn't usually require any additional work other than the initial process, there are one or two caveats to doing this that deserve attention. One relates to something called "triangle stripping" ("tri_stripping", "triangle strips", "tris strips", "triangle strips"), the other to the "concave" and/or "convex" surfaces that result from the process.

Once a mesh has been tessellated and reduced to a 'soup' of triangles (tri-soup), in game that data is run through a procedure referred to as "tri stripping" which is essentially an optimisation technique that relates to vertex and triangle data organisation and how efficiently it can be processed. To help illustrate this concept better and its affects on models, shown below are two versions of the same mesh; the left side shows the results of initial tessellation; the right side a 'fixed' version of said same. Each green and yellow 'path of least resistance' shown approximates the most direct 'route' taken to process vertex and faces data whilst getting from point "1" to point "2", the idea being as mentioned above, to do so as optimally and efficiently as possible.

The original version of the mesh on the left presents a problem however due to the orientation of the final set of faces (far left), orientated as they are counter to the general flow of the structure. This effectively causes the tri stripping process to bounce around that area whilst it tries to quickly resolve the relationship between various vertices and their neighbours - because point "3" can be arrive at from a number of directions the process has to calculate each path before determining which is the most efficient, taking up resources in doing so. This would warrant the original version be 'fixed' by using "Edge Flip" to change the orientation of the problematic triangles (shown below). To do this select the offending elements (by 'face', 'edge' or 'vertices') and use "Ctrl+Shift+F", or "Mesh » Faces » Edge Flip" to change the orientation to something more efficient (shown below).

"Tri stripping". Objects need to be processes from [1] to [2] as quickly as possible, avoiding any bottle necks, [3], cause by inefficient structure

Use Ctrl+Shift+F to flip the orientation of an edge

This is the essence of tri-stripping, a 'best fit' organisation of mesh data. For axial, man-made objects and items, optimisations of this nature are relatively straightforward to put into place. Organic or curved surfaces on the other hand, may present much more of a challenge - it's also one of the reasons modelling should be carried out in 'quads' so organisation of vertex and face data makes logical sense relative to the shape and structure of the object from the get-go.

Organic or curved shapes can often display issues after tessellation due to the way faces orientate themselves to being either "concave" or "convex" relative to their relationships with other surfaces on an object. A typical 'quad' (two selected triangles) for example, can have a shared (usually diagonal) edge - bottom-left to top-right (|/|) or top-left to bottom-right (|\|), which upon flipping may cause an area to appear 'collapsed' or 'protruding' from the overall surface area.

In the images below the rock wall section of the corridor model used throughout this tutorial is shown from the 'outside' after tessellation (for clarity, the player wouldn't normally see this). Two triangles are selected which as a group with a shared edge, can be orientated either 'up/down' or 'left/right' relative to their immediate surroundings. As a result of this the shapes and contours of the area change so the macro-structure of the rock appears to travel further up the mesh with 'up/down', or blocked when using a 'left/right' arrangement. Apply this to an entire model and the random organisation of each triangle can have undesired results. This is one of the reasons why it's best to manually triangulate a mesh as automated scripts don't know what the data being parsed is meant to represent.

With an edge orientated in one direction, the shape of a mesh takes on a particular structure...

Although 3D Studio Max (where the ASE format originates) does allow the export of animated ASE models, it's not a common requirement for game development so Blender doesn't provide this capability. If a model does need to be 'animated', i.e. move in game, it's typically done through the use of scripts and other game related entities. Alternatively, models can be exported to a more appropriate formats such Collada DAE or MD5, both of which support bone-based armatures and associated animation.

Make sure mesh objects have UVW maps applied

Similar to the above. All meshes need to have UVW maps present otherwise the game engine in which the model is being used has no information about texture placement over the object; that's what UVW maps are for.

Remove unused material assignments

If this is not done, the wrong materials are typically applied over the mesh because the game engine can't correctly determine what the material assignments should be, so often apply the first reference found over the entire mesh.

Collapse mesh

This tends to cause similar problems to leaving unused materials in place if not done because the engine can't determine what the material assignments should be relative to the number of geometric objects found when parsing the model data.

Select object(s)

Make sure to properly select objects for export else models appear incomplete or blank. When making a selection from a number of objects always be sure to make one the 'primary' object (the outline will change to a brighter colour than the others).

'Fix' object position

Tends to cause misalignment and placement issues when models are loaded into games. Make sure to allow for objects to be buried or merged into other objects else other related issues may result. Also bear in mind the items Origin point relative to models that are to be tiled.

Centre objects point of origin at grid 0,0,0

Similar to the above, make sure the eventual model is correctly positioned relative to the technology it's being used in, and, the way in which it's to be used. For example, models used in BSP based engine tech (*.map) often requires the origin to be placed in the objects centre of mass so it can be buried in brush volumes without the inherent risk of breaking the entity and causing map/bsp 'leaks'.

Triangulate all mesh sections

Forgetting to triangulate the mesh often results in models appearing 'faceted' in game; the export process and game engines generally don't make any assumptions about what they should be seeing, so if not explicitly 'instructed' to do something - like applying global smoothing after tessellation - then it won't be done or it'll be done incorrectly.

Intact mesh smoothing

Double check to make sure that vertex splits are retained on export - this may mean loading the mesh into a model viewer or other source to see if problems in this area persist. Additionally check the internal structure of the data because certain games engines will 'break' mesh smoothing if it's not in a recognisable format despite being physically present on a mesh (this may be script version/support dependant).

Export

Depending on the script used, exporting is usually prevented if there are errors in the data being processed, if that happens, go back through the checklist to make sure nothing has been missed.

KatsBits provides freely available game and content making tutorials and resources, helping Visitors build their own games, or go further, Game Design Studios!. At KatsBits we strive to bring relevant material to our Readers and forefront Blender as a general game development tool.