What is the optimal approach for collision-detection with the environment in an 3D engine (with triangle mesh based geometry, no bsp)?

A) Use the render mesh

  • [+] no need for additional work for artists to fiddle with collision detection
  • [-] high detail is harder for physics calculation
  • [+/-] maybe use collidable flags for materials
  • [+/-] compute the collision-mesh from the render-mesh

B) Use an additional collision mesh

  • [+] faster/more optimal collision-detection
  • [-] additional work (either by the artist or by the programmer who has to develop an algorithm to compute it from the render-mesh)
  • [-] more memory useage

How do AAA title handle this? And what are the indie dev's approaches?

  • \$\begingroup\$ I would choose the collision mesh for sure. Computing a bounding box or bounding sphere programatically is a trivial task. The artist doesn't need to be involved most of the time. Eventually they might wish to tweak the collision shape for a main caracter/etc, but this is the exceptional case. The rest is automated. \$\endgroup\$
    – glampert
    Jun 11, 2014 at 1:22

2 Answers 2


You do not want to use the render meshes exclusively (if at all).

Back in the days of Quake 3, its curved surfaces (quadratic bezier patches) were evaluated at load-time using a "Geometric Detail" user setting for tessellation quality. If collision were done against those surfaces it would have killed CPU performance. So instead brush planes were used, they approximated the curvature of the surface several orders of magnitude simpler for the sake of collision.

Doom 3 did away with this, and evaluated curved surfaces at level build-time... there were several reasons for this, but it meant that collision geometry was once again relatively static. Modern games are back to the point where patch-based surfaces are evaluated using varying degrees of quality at render-time (DX11/GL4 tessellation). You cannot possibly hope to match your collision geometry against what is being rendered on screen when it is dynamically tessellated (you also would not gain much by implementing such fine-grained collision), so that actually necessitates separate simplified collision geometry.

In fact, gameplay often relies on collision against things that are never actually rendered. There are collision meshes to keep AI from taking certain undesirable paths, to prevent players from running off into the distance, and so on. You will probably never get away with simply colliding against the rendered geometry in a reasonably sophisticated game.


I would leave this decision to the artist:

  • Option to enable collision flag for low poly models
  • Option to also enable invisible flag for additional collision mesh

I worked with Cryengine and there it was also handled similar, but the "collision" material´s invisibility was not a option.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .