Game models, physics, collision hulls & meshes

If you're modeling content for games and 3D media it's likely that you will need to think about collision at some point. Although most games can handle a models native structure without too many concerns over performance, on a large project however, doing this can seriously overwork the CPU, GPU and memory system, having a heavy 'cost' as those processing resources are prioritised to deal with material that could be better optimised to run more efficiently. Where modeled objects are concerned, this is where collision hulls come in to play.

What is a collision hull mesh? ^

A collision hull is usually some form of simplified duplicate mesh of a 'parent' object, a simple cylinder that surrounds a complex Gothic pillar for example. This reduced version acts on behalf of its parent object, which in turn is used by game engines for the detection of impacts, collision and physics - in effect optimising the amount of prioritisation a computer has to do to calculate player and user interaction within the game environment. By using a collision hull, all the fiddley, small or fine details used by a model to describe its visual appearance and structure can be left in place without the associated processing costs.

How are collision meshes set up? ^

That depends on the engine or physics technology a particular game engine is using - a model is composed of either separate objects that are grouped by the export process, or, are attached to each other to form a single model before being exported. So what we have from the point of view of a 3D artist is the possibility of exporting a model with collision hulls in one of two ways;

• As a separate or detached mesh object (sub-mesh/object)

• As an inclusive or attached object

It's important to understand the distinction between the two because although both procedures produce 'a' model, the internal workings of that model will vary significantly depending on which set up was used before exporting to game. To explain this further the images below present an object, a 'corridor' prefab section that's composed of four individual parts - a 'floor', 'walls', 'hull' and 'collision'. Each part has a single material applied to it as well as being UVW mapped with either a 'tiling' and 'unique' texture so the eventual object overall will have several materials and a combination of UVW map 'types', something that's quite typical when producing models for any type of project.

When we put all of those components together, making what is then the final form the object will take once it's exported to game, we just have a collection of individual parts that simply fit together like a jigsaw puzzle. It's at this point that consideration needs to be given to the technology requirements of the engine in which the object is going to be used, something discussed in the next sections.

Collision hull as a separate sub-object mesh ^

As outlined above, collision hulls can either be separate sub-mesh or part of a parent object. For example, if you were making content for use within an Unreal (UE) powered game, Unreal Development Kit (UDK) or a similar styled engine, then your collision meshes need to be set up as 'sub-object'. Using the example corridor shown throughout this tutorial, that would mean a game ready model being composed of two 'sub' objects;

1. the main mesh (the part of the model that equates to there being a 'floor', 'walls' and a 'hull')

2. the collision hull (comprising just the collision mesh itself

The hierarchy of an object like that would look similar to the following;

• 'corridor' object

  • 'corridor' mesh

    • ('Floor')

    • ('Wall')

    • ('Hull')

  • 'corridor' collision mesh

    • ('Collision')

For Unreal tech specifically the game still needs to know which mesh is the collision hull, for that it makes use of an "OB:" name prefix "UCX_" - an object called "corridor" would have a matching collision model called "UCX_corridor" - in Blender the objects name is in the "Links and Materials" panel under the "OB:" heading. The "UCX_" prefix identifies the collision object to the engine which then treats it appropriately.

DESIGN NOTE: names are case-sensitive so "ucx_collision" isn't the same as "UCX_collision". There as a number of different pre-fixes available for Unreal Editing so be mindful of that when making content. The same may also hold true of other engines that employ the same sub-mesh principle, different pre-fixes have different functions and purposes. UCX_ is also just one of a number of available types of object markers.

It's worth noting here that using this approach to setting up collision models may mean it doesn't necessarily need to be fully UVW mapped or materialed, although it may still need to be done for the sake of exporting a finished model (some scripts will refuse to export anything or will export a broken object if no material or UVW map assignments aren't present), certain game engines may not actually require anything other than raw polygons (and an 'identifier') as it's generally the physical structure of the mesh that defines 'where', 'what' and 'how'.

Collision as an inclusive part of an object mesh ^

The other type of collision hull is an 'inclusive' one, one that's part of a model itself. A mesh set-up in this way exports to game engines, like idtech, as a single unified object - the 'mesh' pulls all the separate elements together in to one larger object. The hierarchical structure differs from that of a sub-meshed object, looking similar to the following;

• 'Corridor' object

  • 'corridor' mesh

    • ('Floor')

    • ('Wall')

    • ('Hull')

    • ('Collision')

Because the collision hull is combined in to a larger mesh it can't be identified at the sub-mesh level in the same way as was in the previous 'chapter' above. So, in order to identity the collision hull it has to have a specific material applied to it, one that identifies surfaces as 'collision', which are then treated appropriately by the game engine being used.

Multi-materials or multiple materials ^

Because of the way objects are being set up, particular attention needs to be paid to texture and material assignments and how they relate to the format models are eventually exported to for in game use. So although a model can be exported as a single unified mesh object, how materials are used by the game engine dictates how the model is set up.

To explain this further, there are two ways to export a model to any given format, it can be exported as a single unified object using "multi-materials" and/or, it can be exported as a series of individual objects each with it's own material - an eventual object using "multiple materials". The hierarchical structure differs for each, so an object with multi-materials applied looks like this;

• 'corridor' object (multi-material)

  • 'corridor' mesh

    • 'Floor' material

    • 'Wall' material

    • 'Hull' material

    • 'Collision' material

Where as an object set up to use 'multiple' materials will look similar to the following;

• 'corridor' object (multiple materials)

  • 'Floor' mesh

    • 'floor' material

  • 'Wall' mesh

    • 'wall' material

  • 'Hull' mesh

    • 'hull' material

  • 'Collision' mesh

    • 'collision' material

A couple of issues to watch out for here is whether the game engine being used can see both multi-materials and sub-objects when the collision hull needs to be separate. In other words, can it use this;

• 'corridor' object

  • 'corridor' mesh

    • 'Floor' material

    • 'Wall' material

    • 'Hull' material

  • 'corridor' collision mesh

    • 'Collision' material

Instead of this;

• 'corridor' object

  • 'corridor' mesh

    • corridor material

  • 'corridor' collision mesh

    • 'collision' material

The latter would usually mean having to create a 'unique' material and texture image, inclusive of what were originally the separate sub-meshes, and to which the entire object would now need to be mapped. So a single material in its entirety would look like the following in Blender;

• corridor object

  • corridor mesh

    • corridor material

      • corridor texture

This may seen a little confusing at first glance but it's something that needs to be considered, especially with regards to the format being exported to; an ASE model for use in Unreal for example, means that the object needs to contain no more than two sub-meshes - the object itself and the collision hull. In doing that materials are collapsed into a 'multi-material' on the main object, the collision with its own. Conversely, exporting the same ASE model for use in idtech requires the model to be split into sections per material assignment meaning the collision hull is a sub-mesh alongside any others. In both instances getting this wrong results in broken materials in their respective engines.

General object, sub-object hierarchy ^

Something important to note here is that although a mesh is being exported as a single object, that object may or may not be exported using 'sub-objects' in a similar way as described above. The reason for this is that although collision and surface type recognition is still going to be based on material and texture information, the file format, and how it's used by a game engine, make it necessary for meshes to be composed of separate 'sub' objects. For example, exporting the 'corridor' model as an *.ase model for use in idtech engines would require the mesh to be split per-material; mesh sections using the same material can be exported together as a unit; meshes using different materials need to be exported as different sub-objects.

So in the images below, although the model is to be set up so that it uses 'materials' to distinguish surface characteristics, the mesh can be exported either as a set of sub-objects (the top image), or a 'collapsed' mesh where all the sub-objects are connected to a 'parent' in the hierarchy; the first preserves the objects as separate units, keeping their names, material and texture references; the latter collapses everything under a parent mesh leaving only the materials as separate references, although still under a 'parent' hierarchy.

Before exporting, it needs to be determined which hierarchical structure works within the engine being used, typical errors when getting this wrong would have the same material applied over everything, or the mesh would appear black, because the technology can't determine what it's looking at properly.

Collision hull mesh structure ^

As briefly mentioned above, the collision mesh is a simplified version of the parent mesh. This will usually be constructed of either objects made from a single or series of 'primitives' ('cube', 'tube' etc. shapes), or where that's not possible or practical, a reduced poly-count version of its 'parent' mesh; as is the case in this tutorial in using a model whose visible surfaces are not regular in shape or form.

In dealing with the latter, because we're adding collision to an object that has irregular surfaces upon which the player or game-play mechanics need appear to be interacting, it means making an approximation of the physical characteristic of the visible structure of the object that can be seen during normal game play. In other words, players need to appear to collide (in a generalised way) with the object when in fact it's the hull with which they are in collision, not the actual visible mesh (the rock walls in this instance).

This presents a problem however. Because collision hulls are simplified objects, that often means on irregular surfaces particular attention needs to be given to the placement and shape of the hull so as to minimise the amount of 'clipping' that occurs where the player or game object may be able to penetrate or intersect visible geometry before being stopped by the collision hull (often with the result that the player can see into the void).

In the images below for example a selection of 'shapes' are presented highlighting the structural variety possible that collision hulls could take in relation to the model, game play mechanics and collision requirements of a given game engine; this essentially means that some level of compromise is going to be needed in order to get a functioning collision system set-up that has low over-heads but at the same time is reasonable detailed enough to not cause the aforementioned clipping issues.

Collision 'primitives 'open' or 'closed' objects ^

Hand-in-hand with collision hull simplification is the hierarchical structure of any given hull in of itself as an object - this is something that's heavily dependant on the engine technology being used and whether the system is looking a 'surfaces' or 'volumes' (or both, although generally speaking it's usually one or the other) and how that then influences the physical structure of the collision hull itself. What is meant by that? It relates to how engines 'see' what they render; 3D content is usually made in one of two ways for games, it's either an 'open' mesh or 'closed' object - open meshes tend to be 'surfaces', 'skins' or 'layers', 'closed' objects are 'containers', 'volumes' or 'blocks'.

Take a look at the images below. The top two show the collision hull as a 'skin' or 'open' mesh - it's likely the engine an open mesh is going in to will be looking at 'surfaces' or 'material' assignments to tell it what attributes particular objects have. An example of this type of engine would be idtech where the technology ostensibly uses 'materials' and 'surface flags' as a way to distinguish object properties.

Conversely the bottom image shows the hull as a 'closed' or 'volumetric' object, its collision attributes being based on its physical characteristics as said 'object' - volume based collision tends to be made from either closed meshes as shown below or from simple primitive block shapes stacked and butted together in various ways to define the collision characteristics of an object. An example of an engine using this type of object would be Unreal, where collision is based on 'closed', 'solid' objects (which can be modeled or Unreal Editor placed BSP brush volumes).

Conclusion ^

Although collision hulls tend to follow the same general principles irrespective of engine tech, specifics to do with a hulls physical characteristics and how those get implementation aren't - an engine and what it expects to see dictate what technical necessities are associated with modeling collision hulls; do they use materials or surface flags? Do they need to be volumes (blocks) or surfaces? And so on. It goes without saying here that before making collision hulls for your own models and objects you'll need to understand what the engine you're working with is expecting to see, and this usually involves either reading through available documentation or importing an asset from a game into a 3D application for closer inspection, or both. Once you've done that and can see what's needed you'll be able to then build hulls correctly as per the dictates of the engine being used; most problems and issues that crop up are more likely a result of incorrect set-up rather than necessarily being issues to do with the objects directly (i.e. 'bad' models).