Chapter 836: Physics (Manual)

Core Idea

Three.js has no built-in physics; simulating gravity, collisions and forces means running a separate physics world and syncing its results into three.js meshes each frame, typically via one of three integration approaches with different setup-cost/performance trade-offs.

Key Concepts

• Parallel simulation model: a physics engine maintains its own bodies/world independent of three.js; every frame you copy each body's position/rotation into the corresponding Object3D.
• Fixed physics timestep: physics is commonly stepped at a fixed rate (e.g. 30Hz) independent of the render/game-loop rate (e.g. 60fps), for simulation consistency, while mesh transforms are updated from the latest physics state each render.
• Approach 1 — Three.js physics addons: wrapper classes in examples/jsm/physics that handle world setup and mesh syncing for several popular engines, fastest to get started with for standard cases.
• Approach 2 — JS/TS physics libraries (e.g. cannon-es): lightweight, web-native engines you wire up yourself, manually copying position/quaternion from each physics body to its mesh each frame. Some libraries in this category are actually thin wrappers around a separate standalone engine.
• Approach 3 — WASM-compiled engines (e.g. Ammo.js, a Bullet Physics port; Rapier): highest performance/precision/stability for complex simulations, at the cost of more setup work around WASM memory management and API interaction.

Key Takeaways

1. Three.js provides rendering only — physics requires a separate engine and manual per-frame synchronization of positions/rotations into meshes.
2. Stepping physics at a fixed rate independent of the render rate keeps simulation behavior consistent regardless of frame rate.
3. Official three.js physics addons are the fastest path for standard use cases; hand-wiring a JS engine like cannon-es gives more control; WASM engines like Rapier or Ammo.js give the most performance for demanding simulations at the highest setup cost.
4. Some "JS/TS" physics packages are actually bindings to a separate standalone engine underneath — check what a library is actually wrapping before assuming its performance characteristics.

Connects To

• No specific API-reference chapters — physics engines are external to three.js's own class reference.