Collision Meshes for Game Assets (Godot, Unity, Unreal…)

With the continual development of Godot, Unity, Unreal et al, 3D assets no longer need to explicitly include collision meshes or hulls as part of a given objects package as they tend to be, depending on the type of object or user interactions needed in a given situation, auto-generated by proprietary physics and collision solutions. With that said, manually creating collisions meshes or hulls is still useful, even when using modern game development tools.

Important: due to the number of collision types most modern game engines/development suites have available, there isn’t a succinct uniform way to export assets with collision such that they are automatically recognised and assigned the appropriate collision type upon import (a number of ‘tags’ can be used but this doesn’t guaranty correct conversion). This means exporting collision meshes (hulls) from Blender is largely organisational, so collision can be clearly seen and then appropriately edited as required once imported into the game-editing suite of choice.

Convex vs. Concave

The simplest way to visualise a collision hull is to view an objects bounding box. In Blender enabling Bounds [1] displays a wireframe around a selection that represents the objects total volume, essentially the amount of primitive space it occupies. In its simplest form collision is typically a convex cuboid or rectilinear shape of some kind (default Box). In other words, for the shape to considered a valid convex form there should be no indentations, undercuts, holes or other types of ‘negative‘, or concave, structures – collision is, or should be, a primitive made from axial, aligned surfaces. Similarly, this is also true of collision meshes used for games, they too should be convex structures that have no ‘negative’ or concave shapes.

Design note: to enable wireframe outline, in Object Properties click the Bounds checkbox option in the Viewport Display subsection to enable and set the type of primitive to use, typically Box – all the primitive shapes used to describe an objects bounds in Blender are convex.

In Blender, Bounds [1] represents the volume the object occupies, the shape being analogous to a convex collision hull.

Blender Bounds

With the above in mind, the shape collision takes depends largely on the objects physical attributes and the role it’s supposed to perform in-game, walls for example, generally have different collision characteristics to those of usable items, a sword or throwable ‘acme bomb’, both utilise different collision models that accommodates those differing functions. Here then, it might be possible to use the aforementioned Bounds setting in Blender to determine an appropriate shape a given object might use for its collision mesh.

Design note: modern game development suites are better able to utilise curved and/or organic forms but due care may still be applicable when using more complex shapes for collision meshes and hulls.

The different types of primitive shapes used for Bounds in Blender that can also be used to assess collision mesh shapes.

Primitive Shapes

Looking at the available Bounds shapes then, it’s possible to use those as the basis to determine collisions meshes that cover most circumstances. For example, the acme bomb shown is ostensibly a sphere with a cylinder sticking out the top but, depending on the integration needed from the object in-game its collision could just as easily be a box.

Important: as collision implies physics, complex shapes will use more resources than simpler ones. In practice this might mean there being multiple versions of the same object, each catering to different requirements; the collision hull for a ‘spawn item’ or ‘pick-up’ does not need to be complex because the object doesn’t invoke complex interactions with the world or player other than being a placement or positional ‘marker’, whereas a usable weapon might, as that may need to bounce off walls, floors, be held in the hand and/or thrown.

The different types of collision an object might use; a simple ‘box’, a ‘compound’ object made from different shapes, and a ‘complex’ shell that more accurately fits the items form and function.

Compound Shapes

As a general rule of thumb collision hulls need to conform to one, or both, of the following rules, they must be;

• convex shapes.
• uniform and solid.

However, a collision hulls final form can appear concave [1] in part of whole so long as they are themselves;

• an object made from other convex shapes (compound object).
• each convex shape is closed or solid (no ‘leaks’).

What this means in practice is that each mesh forming part of a compound collision hull, should themselves be ‘valid’ as individual objects, that is, be convex and have no gaps, voids or open (sur)faces.

Important: check engine documentation to confirm compound objects can be used for collision.

Design note: a ‘closed’ or ‘solid’ mesh would be one where, were it to be filled with liquid, won’t ‘leak’ or ‘spill’ its contents regardless as to what’s done with the object.

The overall form of a collision hull can have concave elements [1] (image: left) so long as it’s a compound object formed from other valid convex objects (image: right).

Complex Meshes

A complex mesh is generally going to be more accurately shaped to fit the game-object, subject to the requirements discussed above; convex (sur)faces and be a closed mesh. However, because surfaces have to be convex this can mean a certain degree of compromise has to be had to meet the aforementioned requirements. In practice this might mean collision hulls not being quite as accurate as needed while generally being more efficient than other approaches.

Design note: generally speaking most auto-generated solutions to collision hulls will be similar to manually created complex meshes.

Complex collision hulls generally match the shape of an object more closely (image: left) but will be subject to the same requires as other approaches; be convex and/or closed meshes.

Export Collision

Generally speaking collision meshes can be exported as part of the same file as the game asset they provide collision surfaces for, as part of the same unified mesh, and essentially identified based on material assignment [2], or as a sub-mesh [3] with their own material assignment. How this is done exactly, will depend on the engine tech used and how they define collision objects and/or materials; separate object set-ups might require meshes be identified with a tag, pre or postfix that’s recognised during import, e.g. “_col“, or similarly for materials.

Design note: collision is generally not visible in-game so UV maps and materials are not strictly necessary, however, they may need to be assigned for completeness and prevent possible mesh/compiling errors.

Collision hulls will generally be joined to a game object forming a single object (image: top) [2], or be included as a separate sub-mesh (image bottom) [3]. In either instance the label attributed to the mesh or material is used to identify objects or surfaces as collision.