Colliders: How a Game Knows That Two Things Have Touched

A game world is, in a certain sense, a world of ghosts. The walls the player sees are only coloured triangles drawn on a screen, with nothing to stop a character from passing through them as fog passes through a fence. Every sensation of solidity, the thud of a crate landing, the sword that stops at a shield, the hero who cannot walk into the sea, must be added deliberately, by giving objects a second, invisible body that the physics engine can feel.

In Unity that invisible body is the collider. It is a component, attached to a GameObject alongside the renderer, that describes a shape in space for the purposes of contact and nothing else. The physics engine never looks at the textured model; it looks only at colliders, testing which of them overlap or are about to, and from those tests it decides what has touched what, where, and how hard.

This article examines those shapes with some care. It describes the primitive colliders and the mesh collider, the rule about convexity that so often surprises newcomers, the art of building one solid body from several simple pieces, the reasons the felt shape should differ from the seen one, and something of the engine that does the work underneath. The aim throughout is to explain why the choices matter, not merely which boxes to tick.

The primitive shapes

Unity's three primitive colliders are the BoxCollider, the SphereCollider and the CapsuleCollider. Each is described by a handful of numbers: a box by its centre and size, a sphere by its centre and radius, a capsule by its centre, radius, height and the axis it runs along. Because the shapes are mathematically simple, the engine does not need triangles to represent them. It tests them with compact formulas, and those formulas are among the fastest operations in the whole physics system.

The sphere is the simplest of all. Two spheres overlap exactly when the distance between their centres is less than the sum of their radii, a single comparison that needs no rotation and no edges. A sphere of radius one at the origin and another of radius one point five, four units away along an axis, do not touch, since two and a half is less than four. Move the second to two units away and they overlap by half a unit.

The capsule, a cylinder with rounded ends, is the traditional shape for characters, and for good reason. Its rounded base slides over small steps and uneven ground instead of catching on edges, and its smooth sides let it glide along walls. Unity's CharacterController component uses a capsule internally for the same reasons. Boxes, meanwhile, suit crates, walls, floors and most of the rectilinear furniture of a built world, where their flat faces rest stably on one another.

The mesh collider and the convex rule

When no primitive fits, the MeshCollider takes an actual mesh and uses its triangles as the collision shape. This gives a faithful surface for irregular things such as rocky ground, the inside of a cave or a winding staircase, and for static scenery it is often exactly right. The physics engine builds an acceleration structure over the triangles so that it does not have to test every one of them, but each contact still involves far more work than a sphere or box would need.

The rule that surprises newcomers concerns movement. A MeshCollider attached to a Rigidbody that is moved by the physics simulation, a dynamic or non-kinematic body, must be marked convex. Unity will not simulate an arbitrary concave triangle soup as a freely moving body. Concave mesh colliders remain perfectly usable on static objects and on kinematic bodies, which are moved by script and never pushed by the simulation, but the moment gravity and impacts are in charge, the convex box must be checked.

A convex shape is one without dents or hollows: a straight line between any two points inside it stays inside it. When the convex option is enabled, Unity computes a convex hull around the mesh, as if a sheet of plastic had been shrink wrapped over it, and limits that hull to at most 255 triangles. A bowl marked convex therefore becomes a solid lump, and a ball dropped into it will rest on its rim, because the hollow the eye sees has been filled in.

The reason for the rule lies in the mathematics of contact. Between two convex shapes, the engine can find the deepest point of overlap and a single direction to push them apart using efficient, well behaved algorithms. Between concave shapes moving freely, overlaps can occur in many places at once, in pockets and folds, and resolving them reliably every step is far harder. Restricting moving bodies to convex shapes keeps the simulation stable and its cost predictable.

Building bodies from simple pieces

Real objects are seldom a single box or sphere, and the answer to an awkward shape is usually not a mesh collider but several primitives arranged together. A chair can be a flattened box for the seat, a thin box for the back and four slender boxes or capsules for the legs. If these colliders sit on child objects beneath a single GameObject that carries one Rigidbody, Unity treats them as one compound collider: a single rigid body with a single centre of mass, whose shape happens to be the union of its parts.

Compound colliders are often both cheaper and better behaved than a convex mesh of the same object. A convex hull of a chair would fill the space between the legs, so the chair could never stand over a small object, and it would roll strangely when knocked over. The arrangement of boxes respects the gaps and gives clean, flat contact faces. It also takes a few minutes to build by hand, which is a modest price for an object the player will kick across a room.

The same approach scales up to characters and creatures. A humanoid ragdoll is typically assembled from capsules for the limbs and boxes or capsules for the torso, each on its own bone and joined by joints, rather than a single collider that would bend unnaturally. A wooden palisade of the kind a besieged settlement in Crown & Ashes might raise is better served by a row of tall boxes than by the carved, uneven logs that the renderer draws, since the attackers only need to be stopped, not to admire the grain.

What is seen and what is felt

The render mesh and the collider serve different masters. The render mesh is made for the eye, and an artist may lavish thousands of triangles on bevelled edges, carved ornament and the folds of a cloak. The collider is made for the physics engine, and every extra triangle there costs time on every physics step, time taken from the same frame budget that rendering, animation and game logic must share. What looks right and what feels right are allowed, and usually encouraged, to differ.

Players are remarkably forgiving of this difference when it is handled with taste. A barrel represented by a capsule, a statue by a few boxes, a tree by a single capsule around its trunk: none of these are noticed in play, because the eye is busy and contact is brief. What players do notice is the opposite failure, a collider too detailed for its purpose that snags a character on invisible bumps, or one placed carelessly so that a hand passes through a wall.

There are also cases where the felt shape should be deliberately larger or smaller than the seen one. A narrow wooden beam that the player must cross may be given a slightly wider collider to forgive small errors of footing. A low wall might carry a tall invisible box so that nothing can be thrown over it into an area the designer wants closed. Colliders are a form of level design as much as a technical necessity, a quiet way of telling the player where the world truly ends.

PhysX underneath

Unity's 3D physics is built on NVIDIA's PhysX engine, while its 2D physics uses a separate engine, Box2D, with its own family of colliders. When a scene runs, each collider becomes a shape inside PhysX, and the engine processes contacts in stages. The broad phase compares simple bounding volumes to rule out pairs that are obviously far apart, which disposes of the vast majority of possible pairs cheaply. Only the pairs that survive go on to the narrow phase, where the exact shapes are tested.

This division explains why scene layout affects performance as much as collider type does. A hundred objects scattered across a wide valley produce few candidate pairs, while the same hundred piled into a heap produce many, each requiring narrow phase tests and contact resolution. Unity's layer collision matrix, in the physics settings, lets a project declare that certain layers never interact, so that falling leaves need not be tested against flying arrows, and those pairs are skipped before any work is done.

Colliders also determine what physics queries can see. Physics.Raycast, Physics.SphereCast and Physics.OverlapSphere all test against colliders, not renderers, so an object without a collider is invisible to them however brightly it is drawn. A selection system that relies on raycasts from the mouse will therefore ignore decorative objects unless they are given colliders, and will hit invisible walls that the player cannot see, which is sometimes intended and sometimes a long evening of confusion.

Choosing well

A practical order of preference follows from all of this. Reach first for a primitive, then for a few primitives arranged as a compound collider, then for a convex mesh collider with a simplified mesh, and only for a concave mesh collider when the object is static scenery whose exact surface matters. Each step down this list buys fidelity at the price of speed and, for moving objects, stability. Most of a well built scene lives near the top of the list.

Scale deserves a word of caution. Colliders follow the transform, so scaling a GameObject scales its collider, but primitive shapes cannot always follow non-uniform scaling faithfully. A sphere cannot become an ellipsoid, so Unity sizes it from the largest scaled axis, and a capsule behaves similarly across its width. When an object is stretched unevenly, it is usually better to leave the transform scale alone and adjust the collider's own size or radius instead.

Finally, it helps to look. Unity draws colliders in the Scene view as green wireframes when an object is selected, and the physics debugger can display every collider in a scene at once, coloured by type and state. Comparing those outlines with the rendered geometry quickly reveals the gaps, overlaps and oversized hulls that cause most collision bugs. The invisible bodies of a game are only invisible to the player; to the developer they should be as plain as the furniture.