The Invisible Triage Happening Every Frame

You throw a grenade. It bounces off a concrete wall, clips a metal drum, rolls into a corner with exactly the weight you expected. Convincing. Meanwhile, a barrel fifty metres away wobbles like it's made of anxious air. Nobody patches it. Nobody files a bug report. The engine did precisely what it was supposed to.

Game engines don't simulate physics equally across a scene. They can't. Instead, they run a quiet triage system every single frame, assigning heavier calculation budgets to objects near the player and lighter ones, sometimes near-zero, to everything else. The technical umbrella for this is level-of-detail physics, and once you understand it, you can't unsee it.

The Budget That Has to Balance

A physics simulation is, at its core, a math problem run at speed. For every rigid body in a scene, the engine solves position, velocity, rotation, and collision response. Do that for one object and it's trivial. Do it for four hundred simultaneous objects at 60 frames per second and you're asking the CPU to solve thousands of equations in about 16 milliseconds per frame.

Miss that window and the frame drops.

Engines like Unreal and Unity both expose a concept sometimes called physics LOD, or in Unreal's specific implementation, the "sleep" and "sub-stepping" system. Objects beyond a threshold distance get put to sleep: their physics state is frozen, no forces applied, no collisions checked. Closer objects run at full tick rate. Objects in a middle band run at a reduced tick rate, maybe every other frame instead of every frame.

The numbers vary by engine and developer settings, but a common pattern looks something like this: full simulation within roughly 10 to 15 metres of the player, partial simulation out to 30 or 40 metres, and sleep beyond that. Not universal constants. Tunable parameters. But they illustrate the gradient.

A Barrel, a Bridge, and a Budget Call

Picture a physics-heavy action game. Your character stands at one end of a warehouse with forty physics-enabled crates in the room: twelve within arm's reach, another fifteen scattered through the middle distance, thirteen stacked against the far wall.

The engine assigns those twelve nearby crates full simulation. Every frame, it resolves their mass, their friction against the floor, their collision geometry. You kick one and it spins convincingly because the simulation has the budget to be honest about it.

The fifteen mid-distance crates run at half tick rate. Good enough for most collisions, but the movement might feel slightly laggy if you're paying close attention.

The thirteen far crates? Asleep. Frozen. If a physics object from the mid zone rolls into them, the engine wakes a few, checks collisions, then re-sleeps them. Minimum viable physics. Just enough to avoid an obvious visual lie.

Now walk toward the far wall. Those sleeping crates wake up and get promoted into higher simulation tiers. The twelve you left behind get quietly demoted. The budget shifts with you, invisibly, every single frame. It moves like a spotlight nobody told you about.

What People Misread as a Bug

This is where players misattribute things. You see a physics object behave oddly at range and you call it a glitch. Sometimes it is. More often it's the sleep system doing a sloppy handoff, an object woken mid-trajectory resuming from a slightly stale state.

Here's the real sleight of hand: developers tune the thresholds specifically so the seams are invisible under normal play. You're almost never scrutinising something far away while also caring about its physical accuracy. Your attention is forward, close, immediate. The engine exploits that ruthlessly, and I think that's genuinely elegant, not a shortcut.

Unreal's Chaos physics system, introduced to replace PhysX, added more granular control over which objects sub-step (running multiple smaller physics ticks per frame for precision) and which don't. Sub-stepping is expensive. A falling ragdoll the player is watching closely might sub-step at four iterations per frame. A ragdoll on the other side of the map runs zero iterations. Same asset, completely different treatment.

The Part That Surprises Even Experienced Players

People assume the physics budget is about object count. Fewer objects, better simulation. That's partly true, but it misses the directional logic entirely.

Two games can have identical object counts. One will feel dramatically more physical because its proximity thresholds are tuned more aggressively toward the player's immediate space. The other spreads the budget thin and everything feels slightly unconvincing, slightly like furniture.

Call of Duty multiplayer maps have always been relatively small for exactly this reason: keep the relevant space tight so the engine can afford richer physics where it matters. Open-world games like Red Dead Redemption 2 made a different trade, enormous draw distances and complex crowd systems, but physics objects outside a certain radius are on skeleton crew. Neither approach is wrong. They're different budget allocations for different experiences, and pretending there's one correct answer is the kind of take that doesn't survive contact with an actual frame budget.

So, when you spot that distant barrel wobbling like it's having a small existential moment, are you actually bothered? Genuinely? You weren't looking at it until it moved wrong.

Proximity Is the Whole Argument

The deeper principle is that games are perceptual experiences, not scientific simulations. The engine's job isn't accuracy. It's convincingness at the point of attention. Physics LOD is just that principle expressed in CPU cycles.

A flight simulator and a first-person shooter both simulate physics. The flight simulator cares about accurate aerodynamics at distance because the player literally navigates by them. The shooter doesn't, so the shooter drops them. Every engine decision flows from where the player's attention lands and what it costs to satisfy it there.

The physics you feel when you kick a crate exists because the engine quietly stopped caring about the crate behind you the moment you looked away. That's not laziness. That's the only reason any of this runs in real time at all.