How Does Physics Simulation Work in Games?

Physics simulation in video games is a continuous, frame-by-frame pipeline that converts forces into motion, checks for collisions, and applies impulses so objects respond believably inside the simulated world. Every jump, rollover, and pile-up runs through the same chain of stages before a single pixel renders. How does physics simulation work in games at the engine level: rigid body dynamics governed by Newton’s laws of motion, collision detection, fixed timestep integration, and an impulse-based solver running inside physics engines like Havok, PhysX, and Bullet.

This walkthrough breaks down the entire real-time physics pipeline for game developers, covering motion integration, collision detection, constraint solving, and engine-level performance tricks used by Havok, PhysX, and Bullet.

From Real Physics to Simulated Motion

Games do not simulate reality. They approximate it. Newton’s second law, F = ma, becomes the contract every rigid body obeys each tick, expressed in floating-point math instead of continuous physics. A crate sliding off a forklift is a body with mass, velocity, and a collision shape, not a real wooden box.

What runs every frame is a tight loop with five stages: apply forces, integrate motion, detect collisions, resolve constraints, and hand the result to the renderer. Each stage feeds the next, which is why a bad integration step shows up three stages later as jitter or drift. Most engines, from Unity to Unreal Engine, run this loop at a fixed rate decoupled from the visual frame rate, often 1/60 or 1/50 of a second.

What Every Simulated Object Actually Is

Every object the engine touches carries a small packet of state: position, orientation, linear velocity, angular velocity, mass, and a collision shape. The shape is usually a primitive (box, sphere, capsule) or a convex hull, chosen for speed over fidelity. A wine bottle might be a cylinder, a barrel a stack of capsules, and a boulder a lumpy convex mesh.

Visual fidelity and physical accuracy are different goals. Developers optimize for believability, not truth. Cloth simulation, soft body dynamics, and fluid surfaces exist, but most gameplay still runs on rigid body dynamics, which is cheaper, more stable, and easier to reason about under tight frame budgets.

The Integration Step That Moves Everything

Integration is where forces become motion. Since exact closed-form solutions to the equations of motion are impossible to compute in real time, the engine samples them step by step. Each tick, a body gets a small velocity bump from gravity, friction, or applied force, and that velocity moves the body a tiny distance forward.

That sampling choice, called the integrator, is the single biggest source of “physics feels wrong” bugs. A naive Euler integrator is fast but accumulates error, which is why fast objects can launch into orbit after a few bounces when the timestep varies.

Three Integrators and Their Real Trade-Offs

• ▸Euler integration: Fast and simple. Updates velocity, then position, in two lines. Energy drifts over time, so a bouncing ball gradually floats higher.
• ▸Verlet integration: Stores the previous position and reconstructs velocity from the gap. More energy-conserving, popular for cloth and rope, and harder to apply directional impulses to.
• ▸RK4 (Runge-Kutta 4): Samples the slope four times per tick. Highly accurate, very expensive, and rare in shipping games outside of specific physics sub-systems.

Most real time physics simulation in modern games uses a modified semi-implicit Euler. It stays cheap and damps the worst of the energy gain. The actual answer, though, sits in how the timestep is handled, not just the integrator choice.

Why the Fixed Timestep and Accumulator Pattern Matter

Frame rate fluctuates. Physics should not. A fixed timestep, often 1/60 or 1/50 of a second, runs the simulation in a loop decoupled from rendering, with an accumulator catching up any missed steps. This pattern, popularized by Box2D and Glenn Fiedler’s classic “Fix Your Timestep” essay, is the difference between deterministic physics and chaos across machines.

Decoupling simulation from frame rate matters because a 144 Hz monitor and a 60 Hz monitor would otherwise produce different trajectories for the same scene. Accumulating the leftover time and stepping the simulation in fixed slices keeps replays, networked sessions, and stacked objects stable regardless of render cadence.

“Tip: If a stack of crates jitters at rest, the first thing to check is whether your simulation uses a fixed timestep. Variable-delta simulation is the leading cause of stacking instability.

How Collision Detection Actually Finds Intersections

Doing that with every pair in a scene would cost O(n²), so collision detection splits into two phases: a cheap broad-phase that throws out obvious non-pairs, and a precise narrow-phase that confirms the rest. The broad-phase typically runs spatial hashing, sweep-and-prune, or a Bounding Volume Hierarchy (BVH), while the narrow-phase leans on the Separating Axis Theorem (SAT) and the Gilbert-Johnson-Keerthi (GJK) algorithm.

This split is the single most important performance lever in physics, and it explains why a scene with 10,000 props runs fine while 10,000 active bodies tanks the frame. Filtering first and testing second turns an n² nightmare into a short list of real candidates.

Broad-Phase: Cutting the Candidate Pool Fast

The broad-phase uses cheap bounding volumes to reject obviously non-colliding pairs. Axis-aligned bounding boxes (AABBs) wrap each body, then spatial structures sort them. Common approaches include sweep and prune, a Bounding Volume Hierarchy (BVH), and uniform spatial hashing, where the world is split into grid cells and bodies are sorted into buckets.

Spatial hashing shines when objects cluster in one area. A BVH shines when objects are unevenly spread. Both produce a short list of candidate pairs that survive to the next stage, often 1 to 5 percent of the original pair count.

Narrow-Phase: GJK, SAT, and Convex Hulls

Two algorithms dominate. The Gilbert-Johnson-Keerthi (GJK) distance algorithm is fast for any pair of convex shapes, especially hulls, and can also return a separating vector. The Separating Axis Theorem (SAT) is simpler to implement and the standard pick for oriented box vs. box tests.

Behind both sits the Minkowski difference, a geometric trick that turns “do these overlap?” into “does this combined shape contain the origin?” GJK exploits that directly, which is why it’s the workhorse in Bullet Physics and NVIDIA PhysX. SAT shows up most often in 2D engines and box-heavy 3D games because the math stays short.

Why Tunneling Happens and How CCD Fixes It

A bullet moving 50 meters per second at a 60 Hz tick travels 83 centimeters per step, more than thick enough to skip past a thin wall. That is tunneling: a fast object slips through a collider between frames because discrete collision detection only checks at tick boundaries.

Continuous Collision Detection (CCD), also called swept collision, extends each body into a swept volume that covers its full path during the tick. Tools like Speculative Contacts, used in PhysX, push the body just far enough to touch but never pass through, without the cost of a full sweep.

Detection Method	Best For	Cost	Limitation
AABB sweep-and-prune	Many slowly moving bodies	Low	Poor with large worlds or fast rotation
Spatial hashing	Clustered, evenly-sized props	Low	Hash bucket tuning required
Bounding Volume Hierarchy	Static, complex worlds	Build cost, fast queries	Slow for highly dynamic scenes
GJK narrow-phase	Convex hulls, general 3D	Medium	Convex only; needs EPA for penetration depth
SAT narrow-phase	Box vs. box, oriented shapes	Low-medium	Less general than GJK

Constraint Solving and the Impulse-Based Response

A collision found is not yet resolved. The solver decides how to push the bodies apart, how much friction to apply, and how to keep stacks from collapsing. This stage is where most visible “physics bugs” actually live, even though players blame the previous stages.

Modern engines converged on impulse-based solvers because they handle impacts, friction, and joint constraints in one unified system without unstable force feedback loops. Force-based solvers sound cleaner, but a stiff contact between two heavy bodies produces feedback gains that explode within a few ticks. Impulses sidestep that pathology by correcting velocity directly each iteration.

How Sequential Impulse Solvers Work

After detection, each contact gets a normal (the direction to push apart) and a penetration depth. The solver iterates over every contact, computes the minimum impulse needed to resolve it, applies that impulse, then repeats. After a handful of passes, the stack settles. Erin Catto’s Box2D popularized this approach, and Bullet Physics ships a similar solver in its core.

Fewer iterations mean faster, jittery stacks. More iterations mean smoother stacks and lower frame rate. Eight to ten passes is a common shipping default; stacked-contact scenarios often need double that, and racing sims with hundreds of contact points may push past 20.

Static, Kinematic, and Dynamic Bodies in the Solver

Body type changes the solver’s job completely. Static bodies never move and act as immovable walls. Kinematic bodies move on rails, typically driven by animation or scripts, and push dynamic bodies but never get pushed back. Dynamic bodies respond fully to forces and impacts.

That distinction is why a moving platform sometimes feels like it shoves a player inconsistently. The platform is kinematic, so the solver does not know how to “push back” against the player, it just keeps applying position correction each tick. A small smoothing pass on the platform’s velocity is usually the fix.

“Warning: A common trap is treating a moving platform as a dynamic body. The solver will fight gravity, the platform will sag, and the player will judder. Kinematic is almost always the right choice.

Performance Tricks That Keep Physics Running Smoothly

A perfect pipeline still has to fit in 16 milliseconds. Performance work in physics is not about clever code, it’s about doing less work and doing it in parallel. The biggest wins come from skipping simulation that does not need to run, then parallelizing what remains.

Sleeping Bodies and Island Sleeping

Once a crate settles on the ground, it does not need to be simulated. Sleeping bodies are marked inactive when their linear and angular velocities stay below a threshold for a few ticks. The solver skips them entirely. Island-based sleeping extends the trick: connected groups of resting bodies are slept as a unit, so a stack of 20 crates on the floor costs almost nothing until something disturbs them.

This is the single biggest CPU saver in scenes with lots of props. A warehouse with 5,000 boxes costs roughly the same to simulate as one with 50, as long as the rest are asleep. Drop a heavy barrel onto the pile and the affected island wakes in a single step, then re-sleeps within a second of settling.

Multithreading, SIMD, and GPU Offload

Modern physics engines parallelize aggressively. Broad-phase, narrow-phase, and solver passes each run across worker threads, with SIMD instructions packing four or eight contacts into a single CPU cycle. NVIDIA PhysX goes further, offloading heavy work like fluid simulation, soft body dynamics, and destruction to the GPU through CUDA. Bullet Physics and Havok support similar parallelization on CPU.

The trade-off is determinism. CPU solvers are usually deterministic given the same input order, which matters for replays and networked multiplayer. GPU solvers are fast but harder to lock down bit-for-bit, which is why competitive shooters still favor CPU physics.

Stability comes first, but frame budgets still bite, and that’s where engine-level tricks earn their keep.

Layer-Based Filtering, Query Budgets, and Pre-Fractured Destruction

• ▸Layer-based filtering: Assigns each object a layer and only checks pairs on layers configured to interact, cutting wasted narrow-phase work by 60 to 90 percent in typical scenes.
• ▸Query budgets: Cap how many raycasts or shape queries can run per frame, protecting gameplay code from a sudden spike in expensive lookups.
• ▸Pre-fractured meshes: Artists pre-bake concrete chunks; a hit swaps the intact mesh for the pre-fractured set and activates each chunk as a rigid body.
• ▸Real-time fracturing: Burns the solver, so it stays reserved for cinematic moments rather than gameplay.

Choosing a Physics Engine and Diagnosing Real-World Bugs

The big three commercial and open-source engines are NVIDIA PhysX, Havok, and Bullet Physics. PhysX is the default in Unreal Engine and integrates tightly with NVIDIA GPUs. Havok dominated console titles for two decades and ships inside some Unity builds. Bullet is open-source, used in film and games, and forms the physics core of Blender and robotics stacks. The Open Dynamics Engine (ODE) covers legacy 2D and 3D work.

For 2D, Box2D remains the gold standard. Its deterministic solver and clean API made it the foundation for countless indie hits. Picking the right engine is less about feature lists and more about platform targets, tooling, and whether you need console-grade optimization or open extensibility.

Mapping a Glitch Back to a Pipeline Stage

Tunneling usually traces to missing CCD, not a broken solver. Energy gain, like a ball bouncing higher with each hop, points to integrator drift or a variable timestep. Stacking failures and jitter at rest point at the solver: not enough iterations, wrong friction model, or contact tolerance set too tight. Inconsistent pushback from a moving platform almost always means the platform was incorrectly marked dynamic instead of kinematic.

Building a mental model of the full loop is the difference between fighting physics bugs blindly and solving them in minutes. The cheat sheet: forces, integration, collision detection, solver, render. Pick a stage, and the rest of the diagnosis writes itself.

Quick-Reference Pipeline Checklist

• ▸Forces and integration: Confirm a fixed timestep and check your integrator choice if energy drifts.
• ▸Collision detection: Verify broad-phase structure and enable CCD on any fast-moving body.
• ▸Solver: Raise iteration count, tune friction, and widen contact tolerance when stacks wobble.
• ▸Body types: Mark moving platforms kinematic, walls static, and debris dynamic.
• ▸Performance: Sleep resting bodies, filter layers, and cap query budgets before reaching for GPU offload.

Bottom Line

Every believable crash, bounce, and pile-up runs through the same five-stage pipeline. Once that loop is in your head, you stop guessing and start diagnosing. The integrator moves bodies, broad-phase and narrow-phase find the overlaps, the impulse solver decides who goes where, and the renderer paints the result. Bugs stop being mysteries when you can point at the exact stage they came from.

FAQ