Crash when using Jolt Physics and repeatedly adding and removing bodies while performing physics queries in a tool script

[jon1solution]

Tested versions

Reproducible in v4.5-beta1
Not reproducible in v4.5-dev5

System information

Godot v4.5.beta1 - Windows 10 (build 19045) - Multi-window, 2 monitors - OpenGL 3 (Compatibility) - NVIDIA GeForce GTX 1650 Ti (NVIDIA; 32.0.15.6636) - Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz (8 threads) - 39.82 GiB memory

Issue description

I am profiling a project with ~ 1500 dynamically created collision objects (the creation is not per-frame, but some old collision geometry is deleted and some new collision geometry is created every couple of seconds in my test case). I am testing using raycasts in conjunction with our custom projectile ballistics code, with a target maximum of 2048 projectiles active at a time.

In the latest v4.5-Beta1, when testing with the Jolt 3D Physics engine, I noticed that the raycast times continued to increase. See the Output window in the following screenshot of the MRP:

Here is the (expected) behavior on the v4.5-dev5:

The execution time seems to grow linearly.

Steps to reproduce

The code runs as a tool in the MRP (attached below). The collision objects are generated dynamically, and then a bunch of raycasts are timed. Switch to the 3D preview (and scroll out a little), then make sure the Output window is visible. Every 5 seconds or so the average raycast execution time is printed in the Output. Notice that in the v4.5-Beta1 the execution time keeps increasing, but in v4.5-dev5 it hovers around a lower value (about 3 us / raycast, on my machine).

Minimal reproduction project (MRP)

slow-raycast-jolt-MRP.zip

[akien-mga]

I didn't test, but possibly related to #105746? CC @mihe

[mihe]

I didn't test, but possibly related to #105746?

Given that adding a physics_system->OptimizeBroadPhase() call to JoltSpace3D::flush_pending_objects "fixes" the problem, it's almost certainly a regression from #107454.

Would you mind further explaining your real world use-case for this particular setup @jon1solution? The MRP here pretty much showcases the worst-case scenario with the current approach, where you're ray-casting after every single added body, within a @tool script in particular, thus completely nullifying the batching that replaced the above mentioned OptimizeBroadPhase call in #107454, resulting in some very unfortunate spatial partitioning.

If you're just profiling for the sake of profiling then I would prefer that we leave this as-is.

Also, it's probably important to note that these numbers only apply when done within the editor viewport through a @tool script and not during normal game runtime, as stepping the physics simulation (which doesn't happen in the editor viewport) would perform the above mentioned optimization.

[jon1solution]

Ah, I did not explain my use case well. Please note that this isn't just a performance bug...if you let this MRP continue to run in v.5-beta1 the editor will eventually crash. There are actually 2 different things going on in this MRP:

1. I am adding a single raycast after adding a body as a workaround for Issue # 107366. That workaround is no longer needed in the v4.5-beta1, but this code would still crash when you tested it in the 4.5-dev5, so I left it in. I am not profiling this raycast, it is strictly a work-around.
2. After adding geometry, in this MRP, I an doing a bunch of raycasts as a stand-in for the raycasts my game is using when checking for bullet hits. These are the raycasts I was profiling to try to optimize the projectile code, when I noticed this issue.

In the game, I am generating interior building geometry procedurally as the user gets close to the exterior of the building, then removing interior geometry when it's no longer needed. That drives the removal of old geometry, and the regular creation of new geometry.

We are also doing some minimal projectile physics (drag, wind, gravity) for each of the bullets, with a target limit of 2048 projectiles active. This means I end up running as many as 2048 raycasts for each physics process.

The non-minimal test project looks like this:

[jon1solution]

Just a note: in v4.5-beta1 the average raycast execution time seems to climb pretty linearly with the total number of collision objects that have ever been added. In v4.5-dev5 the time seems linear with the current number of active collision objects.

Is it possible that in v4.5-beta1 the old collision geometry is not being removed when I call queue_free() on the parent Node3D?