Three.js Physics: Cannon.js vs Rapier vs Ammo.js

Three.js is deliberately a rendering library, not a game engine. Physics, like input handling and audio, is left to specialized libraries you compose yourself. This means more setup than an all-in-one engine, but you get to pick the physics library that fits your project's needs (2D vs 3D, performance profile, feature set) rather than being locked into whatever ships in the box.

• Cannon.js / cannon-es: pure JavaScript, small, easy to reason about, good documentation and a large body of Three.js integration examples. The most common starting point for prototypes and games that don't need extreme physics performance. The original cannon.js is unmaintained; use the community fork cannon-es instead.
• Rapier: compiled to WebAssembly, built by the team behind the Bevy game engine's physics. Significantly faster than pure-JS solutions for scenes with many active bodies, with a modern API. The current best choice when physics performance actually matters (many objects, continuous collision detection).
• Ammo.js: a WebAssembly port of Bullet Physics (the engine used in many native games and Blender). The most feature-complete of the three (soft bodies, vehicle physics, constraints), but has the heaviest API and largest bundle size. Reach for it specifically when you need a feature the other two don't have.

For React Three Fiber projects specifically, @react-three/rapier and @react-three/cannon wrap these with hooks that remove most of the manual sync boilerplate described below.

Regardless of which library you choose, the integration pattern is the same: for every mesh that should be physically simulated, create a matching physics body (with its own shape, mass and material), step the physics world forward each frame, then copy each body's resulting position and rotation onto its mesh.

This coupling is manual because Three.js's scene graph and the physics engine's world are two independent systems that know nothing about each other. The sync loop is the only thing connecting them, so a body created without a matching mesh update (or vice versa) is the most common physics bug: objects "falling through the floor" usually means the ground's physics body and its visual mesh drifted out of sync, not that gravity is broken.