Physics in Three.js 3D WebGL

You can move objects manually, but if you want realistic gravity, collisions, and bouncing, you need a Physics Engine.

Hand-rolling gravity by nudging a mesh's position.y down a little each frame works fine for a single falling object, but it falls apart once objects need to collide, stack, or transfer momentum to one another — that requires broad-phase collision detection, contact resolution, and constraint solving, which is exactly what a dedicated physics engine is built to do.

Physics engines like Cannon.js and Rapier run this simulation independently of Three.js's rendering loop, computing positions, rotations, and collision responses in their own internal units before you ever touch a mesh.

Three.js doesn't have built-in physics. We must pair it with a separate physics library like Cannon.js or Rapier.

Three.js only owns the rendering side of the equation — geometries, materials, cameras, and the WebGL draw calls that turn them into pixels. It has no concept of mass, velocity, or collision shapes anywhere on a Mesh or Scene.

Cannon.js (and its actively maintained fork cannon-es) run pure JavaScript physics math, while Rapier is a Rust library compiled to WebAssembly, which makes it noticeably faster for scenes with many simultaneously colliding bodies.

Does the core Three.js library include built-in physics for calculating gravity and collisions between meshes?

The answer is no — THREE.Physics doesn't exist, and there's no gravity property anywhere on a Mesh or Scene. Three.js deliberately stays a rendering-only library so it can be paired with whichever physics engine best fits a given project.

This separation is a common pattern in graphics programming: the renderer draws whatever state it's given, while a completely separate simulation system decides what that state should be each frame.

How does it work? You create a hidden 'Physics World'. Every visible 3D Mesh gets a matching invisible 'Body' in the physics world.

The World object is the physics engine's own scene graph — it tracks every rigid body, its shape, mass, and material properties, completely separately from THREE.Scene. Setting world.gravity.set(0, -9.82, 0) applies Earth-like acceleration to every dynamic body inside it.

Each Body you add to the world is invisible on its own; it's pure math (position, velocity, collision shape) with nothing to render. You always keep a Mesh and a Body as a paired set, one for looks and one for physics.

In your animation loop, you tell the physics engine to calculate the next step, and then you copy the coordinates from the invisible Body to the visible Mesh.

world.step(1/60) advances the simulation by a fixed time slice, resolving gravity, collisions, and constraints for every body in the world during that tick. It doesn't touch your meshes at all — it only updates each physics body's internal position and quaternion.

The copy calls are what actually make the simulation visible: mesh.position.copy(body.position) and mesh.quaternion.copy(body.quaternion) pull the freshly computed physics transform onto the rendered object every frame, which is why forgetting this step is such a common bug — the physics runs perfectly, but nothing on screen moves.

In vanilla Three.js physics, what must you constantly do inside your requestAnimationFrame loop?

The correct answer is copying Body coordinates to Mesh coordinates. Every frame you must call world.step() to advance the simulation, then sync each tracked mesh's position and quaternion from its corresponding body.

Skip the step call and gravity never advances; skip the copy and the physics simulation runs invisibly while every mesh stays frozen in its last rendered position — both are among the most common bugs when wiring up a physics engine by hand.

Doing this manually is tedious. React Three Fiber has a package called @react-three/rapier that abstracts all the syncing for you!

@react-three/rapier wraps the Rapier WASM engine in a declarative React API — the <Physics> component creates and steps the World for you automatically on every frame, hooked directly into React Three Fiber's render loop.

This eliminates the manual world.step() and position-copying boilerplate entirely; you describe which meshes should behave physically using components, and the library handles the Body-to-Mesh synchronization internally.

Any mesh you want to be affected by gravity must be wrapped in a <RigidBody>. It's that simple.

<RigidBody> automatically infers a collider shape from its child geometry by default (a box for boxGeometry, a sphere for sphereGeometry, and so on), and it keeps the wrapped mesh's transform in sync with the underlying Rapier rigid body every frame.

By default a <RigidBody> is 'dynamic' — affected by gravity and collisions — but that behavior can be overridden with the type prop, which is exactly what's needed for objects like floors that should never fall.

In @react-three/rapier, what component must you wrap around your <mesh> so that it falls due to gravity?

The answer is <RigidBody>. Without it, a mesh is purely visual — React Three Fiber will render it, but Rapier has no rigid body registered for it, so gravity and collisions simply don't apply.

A bare <mesh> and a <mesh> wrapped in <RigidBody> look identical the moment the scene mounts; the difference only becomes visible once the physics world starts stepping and one of them starts falling while the other stays frozen in place.

But wait, what about the floor? We don't want the floor to fall! We must set the floor's RigidBody type to 'fixed'.

A type="fixed" RigidBody is immovable — it still participates in collisions (other bodies bounce off it) but gravity and forces never move it, which is exactly the behavior a floor, wall, or terrain mesh needs.

The colliders="cuboid" prop on the falling box explicitly sets its collision shape to a box matching the geometry's bounds, which is more predictable than relying on shape auto-detection for non-trivial geometries.

Let's see a 3D Preview! Because we can't load Rapier here natively, we will simulate a physics drop using pure math and useFrame.

This preview hand-rolls the same gravity-and-bounce behavior a real physics engine would give you, just without collision detection between multiple bodies: velocityY accumulates a small downward increment every frame inside useFrame, and that velocity is added to the mesh's position.y.

The floor collision check (if (position.y < -1.5)) clamps the ball back to the floor height and flips velocityY negative, multiplying it by 0.8 so each bounce loses 20% of its energy — a cheap way to fake restitution without an actual physics library.

And that's it! By combining Three.js, React Three Fiber, Shaders, and Physics, you can literally build anything you can imagine.

With rendering, cameras, materials, shaders, and now physics in your toolkit, you have every core building block a real-time 3D web application needs — the remaining work is mostly about composing these pieces for your specific project.

Physics engines like Rapier scale to hundreds of simultaneously simulated bodies with careful use of fixed timesteps and sleeping bodies (physics bodies that stop being simulated once they come to rest), so what you've learned here is directly usable well beyond toy demos.

You can move objects manually, but if you want realistic gravity, collisions, and bouncing, you need a Physics Engine.

Three.js doesn't have built-in physics. We must pair it with a separate physics library like Cannon.js or Rapier.

Does the core Three.js library include built-in physics for calculating gravity and collisions between meshes?

• →Yes, it is built-in
• →No, you must use an external library

How does it work? You create a hidden 'Physics World'. Every visible 3D Mesh gets a matching invisible 'Body' in the physics world.

In your animation loop, you tell the physics engine to calculate the next step, and then you copy the coordinates from the invisible Body to the visible Mesh.

In vanilla Three.js physics, what must you constantly do inside your requestAnimationFrame loop?

• →Delete overlapping objects
• →Copy Body coordinates to Mesh coordinates
• →Nothing, it's automatic

Doing this manually is tedious. React Three Fiber has a package called @react-three/rapier that abstracts all the syncing for you!

Any mesh you want to be affected by gravity must be wrapped in a <RigidBody>. It's that simple.

In @react-three/rapier, what component must you wrap around your <mesh> so that it falls due to gravity?

• →PhysicsBox
• →Gravity
• →RigidBody

But wait, what about the floor? We don't want the floor to fall! We must set the floor's RigidBody type to 'fixed'.

Let's see a 3D Preview! Because we can't load Rapier here natively, we will simulate a physics drop using pure math and useFrame.

And that's it! By combining Three.js, React Three Fiber, Shaders, and Physics, you can literally build anything you can imagine.