The mesh a player sees and the shape they collide with are different objects, deliberately. Using the render mesh for physics is the single most common cause of a game that runs fine visually and stutters under load.
Why they differ
Collision detection cost scales with complexity, and it runs many times per frame against many objects. A 60,000-triangle prop as a collider is 60,000 triangles the physics engine tests against; a box approximating it is six faces.
The collider hierarchy, cheapest first
- Sphere. Trivial to test. Right for balls, pickups, rough proximity.
- Capsule. Cheap and stable. The standard character collider.
- Box. Cheap. Right for crates, walls, most architecture.
- Convex hull. Moderate. A shrink-wrapped shape with no concavities — right for most props.
- Compound convex. Several hulls approximating a concave object. The usual answer for anything with a hole or a hollow.
- Triangle mesh. Expensive, and usually restricted to static geometry. Right for terrain and level shells.
The concavity rule
Most physics engines cannot use a concave shape as a dynamic collider. A bowl, a doorway, a ring — each has to be decomposed into several convex pieces or treated as static. If a dynamic object behaves as though it is solid where it should be hollow, this is why.
Generated meshes as colliders
Dense, irregular, and often with small non-manifold artefacts — the worst possible input to a physics engine. Always author collision separately, either by hand from primitives or with an automatic convex decomposition, and never by ticking the box that reuses the render mesh.
A useful discipline
Collision should usually be slightly smaller than the visual mesh, not larger. A player who visibly clips a wall corner forgives it; a player blocked by nothing does not.