Wild performance gains between 5.0.0 and 5.5.0

[DocAce]

Hi,

X4: Foundations has been using Jolt 5.0.0 since close to its release in April 2024. We've been holding off on updates since then because we're storing collision shape files in the game assets and thought the update notes didn't contain important enough improvements to make the reprocessing (and increased update download for players) worth it.

Folks, we could not have been more wrong. I don't know exactly what did it, I suspect internal allocation optimizations, but with 5.5.0 the durations of calls to PhysicsSystem::Update() went down by up to 95% in some extreme cases. It's such a stark difference that I've spent more than a day hunting for what I'm doing wrong, but everything from collisions to sensors and raycasts seems to work completely normally.

Hats off to Jorrit and every contributor, you made an already very fast thing even faster!

PS: profile charts for the most extreme difference:

[jrouwe]

As much as I would love to claim credits for this, diffing v5.0 vs v5.5 / looking at the release notes doesn't show me anything that I think could explain this huge difference.

What I notice is that in 5.0 you were spending a disproportionate amount of time on FindCollisions (FindCollisions is usually roughly the same size as SolvePositionConstraints as your 5.5 profile shows). It looks like you were spending a lot of time colliding objects in the MOVING layer that weren't resulting in many collisions.

If you attach the html versions of both profiles so that I can zoom in, I might be able to tell you more.

B.t.w. are you only using 1 thread for physics?

[DocAce]

Heh, I'm sure the "bad" part was entirely on our side and your changes just made our mistakes have less of an effect 😁

Yes, we're currently running single-threaded because some of our code (mostly involving detected contacts) can't trivially be parallelized without adding expensive locks, negating any threading benefits... But we're working on a lockless solution.

Anyway, here are the htmls:

profile_chart_500.html
profile_chart_550.html

[jrouwe]

In your v5.0 profile what we have is a large number of potentially overlapping body pairs (based on their bounding boxes). These bodies are colliding against MutableCompoundShapes in the MOVING layer. Each of those MutableCompoundShape objects contain a lot of sub shapes and they all seem to have 1 StaticCompoundShape with a high number of sub shapes.

In the v5.5 profile, all those are gone from the profile and it only finds 2 potentially overlapping body pairs. There's almost no collision detection work left.

If I had to guess then I think you ran into one of these:

• aff23a0 - A bug fix in the calculation of the bounding box when removing shapes. If you were removing shapes from your mutable compound, you would potentially have gotten a too big bounding box and, if you're really unlucky, resulting in a lot of extra broad phase overlaps and collision detection tests.
• 66ad0ff - A bug fix in MutableCompoundShape::AdjustCenterOfMass. Again this results in an incorrect bounding box and potentially extra collision tests.

If you can try backing out these changes (or just synching MutableCompoundShape.cpp/h to the v5.0 version) then we can confirm if this is indeed the cause. If this turns out not to be the cause, then something must have changed in your collision filtering that causes all these body pairs to be skipped (filtered out). Maybe, based on the description of it being a mutable compound in the MOVING layer with a static compound inside, you know what these things could be and you can test if they still behave as expected.

[DocAce]

That shape setup is correct. Many of our objects, particularly ships and stations, are modular and have a MutableCompoundShape with a child for each "part" (including individually destructible elements like turrets, but also animated parts like hatches or flaps). The child shapes used for collision detection are usually StaticCompoundShapes containing ConvexHullShapes, which are generated by artists using VHACD and written into a binary file by a converter tool on asset export. I can confirm that they still behave correctly: I can properly fly into the hollow parts of large ships and collide with the geometry as expected.

Using the 5.0.0 version of MutableCompoundShape.h/cpp did not change the performance at all. And nothing should have changed in the filtering, either. I literally only updated the SDK, made the small amount of necessary adjustments in our code (including setting a custom Reallocate function) and re-exported all of our collision shape files.

This is a screenshot of the situation I'm looking at, btw. A bunch of ships of varying sizes in a relatively small area:

But your mention of bounding boxes made me look at whether they changed between 5.0.0 and 5.5.0, and indeed for some they did - while most bodies have almost identical ones, there are occasionally ones (30 in my specific test case) with an empty MutableCompoundShape and an invalid / infinite world space AABB! Did one of your fixes end up handling that case gracefully?

[jrouwe]

Did one of your fixes end up handling that case gracefully?

Yes, the first fix I mentioned fixes that.

So, if the v5 mutable compound doesn't slow things down then I have no idea what made things faster. In any case it's good news ☺️