The Barrel You'll Never Watch Land

You kick a crate off a ledge, spin the camera away to deal with something more urgent, then turn back two seconds later. The crate is on the ground, perfectly settled, exactly where physics says it should be.

Except the engine didn't simulate those two seconds. It guessed. And the guess was so good you never noticed.

This is physics sleeping, one of the more quietly elegant tricks in real-time software.

The Problem With Simulating Everything

A physics engine steps through time in small increments, usually between 30 and 120 times per second depending on the game. At each step it recalculates velocity, applies gravity, checks for collisions, and resolves overlapping objects. Do that for one object and it's trivial. Do it for a thousand loose props scattered across a large level and you're burning meaningful CPU budget on things that are, functionally, furniture.

The solution most engines settled on is called sleep states, sometimes called deactivation or hibernation depending on the middleware. Havok, PhysX, and Bullet (the three engines hiding under the hood of most commercial games) all implement some version of it. The logic is the same across all three, even if the tuning differs.

An object gets a sleep threshold: a minimum velocity and angular velocity it must stay below for a set number of consecutive frames before the engine marks it dormant. PhysX defaults to roughly 0.05 units per second of linear velocity, with a matching rotational value, held for about half a second of simulation time. Drop below both thresholds long enough and the object is frozen in place, pulled off the active simulation list, and costs almost nothing to maintain.

Waking it back up is the interesting part. Any contact with a non-sleeping object, any explosion force, any nearby collision event, and it snaps back into the active list instantly. From your perspective, it just works.

Frustum Culling Is a Different Thing (And People Confuse Them)

Before going further: physics sleeping is not the same as frustum culling. Conflating them is the single most common misunderstanding about this topic, and it muddies every conversation that follows.

Frustum culling is a rendering decision. The engine calculates the camera's view frustum, the pyramid-shaped volume of what's actually on screen, and skips drawing anything outside it. The object still exists. It still simulates. The GPU just doesn't render it.

Physics sleeping is a simulation decision. It has nothing to do with the camera. An object can be right in front of you, fully visible, and still be asleep if it hasn't moved in a while. Conversely, an object can be behind a wall, completely invisible, and still be awake because something bumped it three frames ago.

The two systems do interact in practice. Many engines add an extra layer: if an object is both asleep and outside the camera frustum (or beyond a certain distance), they'll despawn its physics representation entirely and keep only a static transform. The object becomes, essentially, a photograph of itself until something relevant happens nearby.

Take a specific scenario. A player in a large action RPG knocks a stack of twenty barrels off a dock, then runs 200 meters away to trigger a cutscene. By the time the cutscene ends, those barrels have been asleep for maybe 15 seconds, are well outside the active streaming radius, and their physics bodies have been fully unloaded. The engine keeps their final resting positions on record, and if the player runs back, it reloads the static props at those saved coordinates. Nobody simulates those barrels bouncing to a stop again. It already happened once.

The Worked Example: Two Players, Same GPU Budget

Consider two players running the same game on equivalent hardware.

Maya plays methodically: she clears a room, waits for debris to settle, then moves on. By the time she's in the next area, the previous room has almost entirely gone to sleep. Her physics thread is handling maybe 40 active objects at any given moment.

Priya speed-runs. She's constantly moving, perpetually triggering new physics interactions before old ones resolve. Barrels are still rolling when she's already kicked over a bookshelf two rooms away. Her active object count spikes to 300 at peak. The frame times show it: a visible stutter every time the solver has to untangle a pile-up she walked away from.

Same hardware. Same game. Wildly different physics budgets, because one player let objects sleep and one didn't. The engine didn't fail. The simulation design just hadn't accounted for a player who generates chaos faster than the sleep threshold can catch up.

What Breaks When Sleep Goes Wrong

Sleep thresholds are tuned per-game, sometimes per-object-type, and getting them wrong produces some of the stranger bugs in physics-heavy titles.

Set the threshold too aggressive (objects sleep after barely moving) and you get objects that freeze mid-air for a frame because they momentarily dipped below the velocity cutoff. Stack boxes incorrectly and they'll lock into an impossible configuration, each one asleep, each one held up by the sleeping object beneath it, the whole structure sitting there defying gravity because no individual object ever registered enough velocity to stay awake. It looks like a glitch. It's actually the system working exactly as designed, which is arguably worse.

Set it too lenient (objects must be nearly perfectly still before sleeping) and you get the opposite: jitter. Small objects like coins or shell casings never fully settle. They micro-vibrate on flat surfaces, never crossing the threshold, burning simulation time indefinitely. Some engines solve this with a secondary check: if an object's velocity variance over a window of frames stays below a certain value, it sleeps regardless, even if instantaneous velocity is slightly above the cutoff. Bullet does this. It's the difference between a coin that sleeps in half a second and one that rattles around for thirty, like a shopping cart wheel that just will not stop.

The best physics designers treat sleep tuning as its own craft. It's not a default you ship with. It's the difference between a world that feels solid and one that feels like it's populated by anxious objects waiting to misbehave.

Ever found a game where dropped items slowly drift across flat floors? That's a sleep threshold set too lenient, combined with a solver applying tiny residual forces it can't fully cancel. The object technically never stops moving. So it never sleeps. So it never stops moving. A loop nobody wanted, running forever in the background.

The engine is always making judgment calls about what deserves the cost of existing in full. Most of the time it's right. When it isn't, the world doesn't fall apart. It just gets quietly, persistently weird in ways that are hard to name until you know what to look for.