What's the reason behind collision-boxes?

Question

I was surprised that some games use extra models called collision-boxes for collision. What is the benefit of doing so? Can't we calculate collisions between the vertices of any game model? Is this possible? Are there performance reasons?

Answer 1

Calculating collisions by using the geometry of the game-model can be really costly in terms of CPU usage (performance). Even more so when you're dealing with detailed polygon models.

To speed calculations up, collision detection is usually done in two phases:

• Broad-Phase: Use very simple bounding objects like spheres or axis-aligned bounding boxes. The goal is to have a very fast way to check for a potential collision. In this phase you can also use specialized data-structures like octrees to rule out lots of objects fast. This is very important in games with lots of objects.

• Narrow-Phase: If you detected a collision during the broad-phase, you can now check if the objects that had touching bounding-boxes/spheres actually intersect. But even in this phase, it's common to use special collider-meshes instead of the actual polygon data of the model. The collider mesh can be much more coarse then the actual model and should also consist of convex bodies to simplify collision-detection (at least that's a common constraint used in physic engines).

So yes, there are definitely performance reasons. It's always a good idea to have a broad- and narrow-phase, unless you only have to deal with very few and simple objects.

The same procedure also applies for 2D. In the broad-phase you can use bounding circles or axis-aligned rectangles. In the narrow phase you can then check the actual outlines of your sprite, for example by using SAT or pixel-perfect collision detection.

Answer 2

Performance reasons are a very important reason, but it's not the only one. If you handled collisions based on the actual models, this is vastly more precise than you actually want, for various reasons. Obviously, you don't have the same level of control over a game character as you do over your own body in real life.

In real life, your standing pose is wider than your running animation, but that doesn't mean you clip into the walls of a narrow corridor resulting in weird physics glitches when you stop moving, because you bunch yourself up to fit. Having a game character do that would require not just a lot more time spent on collisions, but an approach to character animation which takes feedback from physics and environmental cues (which would probably discount pure mo-cap).

Even if it's doable, it's not desirable to have whether or not your character makes the jump dependent on what point in its animation cycle it is. The control you have is an abstraction: the game underneath should also function as an abstraction. The level of that abstraction is different for different kinds of games:

Many times you want the character collision mesh to be a constant capsule. For a fighting game you may want the collision mesh to use some crude representation of your bone structure (although Street Fighter still uses 2D hitboxes defined with frame data). For a first-person shooter, you may want to use different types of hitbox (for example, capsule for movement, and a collection of bone-related shapes for shot resolution).

But you pretty much always want an abstraction: poly-perfect (or pixel-perfect, in the case of 2D) collisions, whether tractable or not, are very rarely conducive to good gameplay.