Teams commissioning a physics engine often assume 3D is 2D plus a coordinate. The engineering reality is that adding the third dimension changes the nature of the solver, and the cost difference is far larger than the dimension count suggests.
Where the difficulty actually jumps
| Aspect | 2D | 3D |
|---|---|---|
| Orientation | One angle | Quaternion; normalisation and drift |
| Rotational inertia | A single number | A tensor that rotates with the body |
| Narrowphase | SAT on polygons — straightforward | GJK/EPA on convex hulls |
| Contact manifold | Usually 1–2 points, easy | Polygon clipping in 3D; unstable if wrong |
| Stacking stability | Manageable | Genuinely hard |
| Continuous collision | Swept circles/boxes | Conservative advancement, much costlier |
| Joints | Simple constraints | Multiple angular DOF to constrain |
| Debugging | Visual and obvious | Hard to see what went wrong |
The three that dominate cost
1. Contact manifold generation
When two bodies touch, the solver needs a set of contact points, not just "they intersect". In 2D a box resting on a plane produces two clean points. In 3D it produces a four-point polygon that must be computed by clipping one face against another, with consistent point ordering and stable persistence between frames.
Get this wrong and everything above it jitters. If contact points shift or change count between frames, the solver receives inconsistent constraints and bodies vibrate on surfaces they should be resting on. Most amateur 3D engines fail here, and no amount of solver iteration fixes it.
2. Stacking stability
Boxes resting in a pile is the classic hard case. Each contact is solved somewhat independently, so errors propagate through the stack, and bodies slowly sink into each other or drift apart.
Production engines address this with warm starting — reusing last frame's impulses — plus persistent contact caching, sufficient solver iterations, and careful penetration correction. It is a lot of accumulated technique, and it is exactly what stock engines have spent years refining.
3. Rotational dynamics
In 3D, angular momentum and angular velocity are not parallel, which produces genuine physical effects like the tumbling of an object spun about its intermediate axis. Integrating rotation correctly requires care, and naive approaches produce visible energy gain or loss.
2D physics is mostly collision detection. 3D physics is collision detection plus a rotational dynamics problem that has no 2D analogue.
What each is genuinely good for
2D is right for
- Platformers, puzzle and arcade games
- Anything where gameplay is planar
- Mobile titles needing tight frame budgets
- Deterministic multiplayer — far easier in 2D
- Educational and visualisation tools
3D is required for
- Vehicle and character simulation
- Training simulators and robotics
- Engineering visualisation with real dynamics
- Any game where objects tumble and stack
- Ragdolls and articulated bodies
The choice studios get wrong
Two mistakes recur:
- Building 3D when the gameplay is planar. A side-scroller with 3D art does not need 3D physics. Simulating in 2D and rendering in 3D is common, cheaper, and more stable.
- Assuming 2.5D is halfway. If objects rotate freely in three dimensions, you have a 3D physics problem regardless of how the camera is positioned. There is no partial credit on rotational dynamics.
The question that settles it: do objects need to rotate about more than one axis? If not, you have a 2D problem — simulate it in 2D, render however you like, and save yourself the majority of the engineering cost.
Scoping either one
Whichever dimension, narrowing scope is what makes a custom engine tractable:
- Which shapes do you actually need? Circles, capsules and boxes cover an enormous amount of gameplay. Arbitrary convex hulls and meshes cost far more.
- Do you need stacking? If bodies never rest on each other, you avoid the hardest stability work entirely.
- Do you need joints? Each joint type is its own constraint implementation and tuning.
- Do you need continuous collision everywhere, or only for a few fast objects?
- Is determinism required? If so, decide before writing code — it constrains threading and iteration order throughout.
Scoping a physics engine for a game or simulation? Tell us what has to move and how. See our physics engine service, determinism, and custom vs Unity's default.