Avoiding Physics Processing Overload

[MrGreenWithAGun]

I have the Jolt physics working with my game engine just fine. I notice that when i have enough collisions taking place simultaneously, especially when several bodies are impacting each other (more than just one on one interaction), things begin to slow down. In my case it has to do with a tank model that has three rigid bodies (base, turret, and barrel) and about a dozen wheels. When they spawn on top of each other or are driven into each other and a pile of them forms, the physics can crush the CPU. And while I know this is not typical of a game in general, it is a "possibility" of occurring.

The problem I am having is that when it happens, the frame rate can drop to the point that recovering control is practically impossible due to the frame rate dropping to around 3 fps. Again, i know this is unlikely to happen, but it can, and it can leave my game engine in a state where playing the game is no longer feasible and terminating the game becomes the only viable choice.

My question is, what are some of the best practices to keep the physics system from blindly going off into the step world function without awareness it won't come back for 300ms? How should i go about handling these kinds of scenarios so that the frame rate never drops below say 20fps due to the stepping taking too long?

[jrouwe]

A physics update of 300 ms is a lot. I don't think I've ever managed to create a scene that does that. E.g. this scene of 160 ragdolls runs in about 3 ms on my computer, and it sounds like it has far more collisions than your scene has. You probably have some sort of configuration error, but without more info there's very little I can do to help you. What hardware are you running on? What configuration of Jolt are you using? Do you have a profile of this scenario (you can use Jolt's built in profiler or an external tool)? What does the rest of the scene look like? Did you setup your broadphase in separate layers for moving / static bodies?

[MrGreenWithAGun]

Your demo actually brings my CPU to a crawl as well. It's an original i7 extreme 2.3GHz.

I compiled Jolt with x86, 64bit, SSE, (SSE4.1, SSE4.2?). My cpu doesn't support the other options. (I did notice on steam that the other options are in nearly all PCs today so yes i will want to take advantage of them, but do you think those would make a difference?)

I don't believe i setup broadphase in separate layers. Not sure what that involves. Would it be significant in how the system performs?

As an aside, i initially implemented height fields for terrain, but the mesh bodies works just fine for my needs and i use them exclusively for terrain. is that an issue i should reconsider?

[jrouwe]

Your demo actually brings my CPU to a crawl as well. It's an original i7 extreme 2.3GHz.

If we're talking about a 1st gen i7 then we're talking 17+ years old hardware? I'm not surprised it doesn't run well then. This is hardware from the PlayStation 3 era, so you'd need to have extremely simple geometry and very low object counts.

I did notice on steam that the other options are in nearly all PCs today so yes i will want to take advantage of them, but do you think those would make a difference?

A bit, but not massively.

I don't believe i setup broadphase in separate layers. Not sure what that involves. Would it be significant in how the system performs?

Yes, this makes a big difference (if you have a significant number of objects that is). The HelloWorld sample shows how to do this:

JoltPhysics/HelloWorld/HelloWorld.cpp

Lines 97 to 107 in eea1f04

	// Each broadphase layer results in a separate bounding volume tree in the broad phase. You at least want to have
	// a layer for non-moving and moving objects to avoid having to update a tree full of static objects every frame.
	// You can have a 1-on-1 mapping between object layers and broadphase layers (like in this case) but if you have
	// many object layers you'll be creating many broad phase trees, which is not efficient. If you want to fine tune
	// your broadphase layers define JPH_TRACK_BROADPHASE_STATS and look at the stats reported on the TTY.
	namespace BroadPhaseLayers
	{
	static constexpr BroadPhaseLayer NON_MOVING(0);
	static constexpr BroadPhaseLayer MOVING(1);
	static constexpr uint NUM_LAYERS(2);
	};

As an aside, i initially implemented height fields for terrain, but the mesh bodies works just fine for my needs and i use them exclusively for terrain. is that an issue i should reconsider?

I would not expect a massive performance difference between the 2. Height fields mostly reduce the amount of memory that's needed.

[MrGreenWithAGun]

It turns out I copied the code from HelloWorld.cpp, so it's setup the way you suggest.

I guess at this point i should run the profiler to see what i can learn.

BTW, I ran through some of your samples to see which had severe performance problems on my machine.

Funnel test 5 fps near the end when they were all at the bottom of the funnel
Vehicle stress test 21 fps
Rig pile test 25 fps
Compound shape test 20 fps

All other tests were generally 60 fps or deviated slightly for only small periods of time if at all. I am guessing that none of these samples should have dropped below 60 fps, yes?

[jrouwe]

I'm not making any guarantees on if tests should run 60 or not, that really depends on your hardware (they do run 60 on my machine, but mine is brand new). FunnelTest is a really heavy one, so I'm not surprised that it runs slow. But I'm guessing that your tanks don't use more bodies than the RigPile test, and since that runs at 25 fps, there must be a mistake somewhere. Are you running in Release/Distribution mode?

[MrGreenWithAGun]

My tank has three rigid bodies, all convex shapes, nothing complicated, and 10 wheels that the physics system "drives".

My test had about 100 tanks on a flat surface, about 8 triangle mesh colliders, and the performance only degraded when i had about 6 tanks piled on each other.

I downloaded the latest jolt source, built it with VS 2026 with SSE 4.1/2 only. Then I ran the release build for the samples and the performance is 60fps for pretty much all of them, including the double precision big world test (which was like 2 fps before).

Both the Rig Pile test and the funnel test hovered just below 60 then settled at 60 at the end.

I am going to try my engine with the release version next.