Manipulating compound shapes after body has entered tree can be slow

[mihe]

This is a formal issue for the discrepancy with Godot Physics that's currently mentioned in README.md:

Manipulating a body's shape(s) after it has entered a scene tree can be costly

Put simply, as soon as a CollisionObject3D has been added to the scene tree (and thus the physics space) any changes to the body's overall shape will force a full rebuild of the body's compound shape, which is slow/expensive. This applies when changing any property of any currently attached shape as well as when adding or removing an individual shape.

The only real workaround for avoiding multiple rebuilds when dealing with multiple shape changes is to do them out-of-tree (i.e. when not in a physics space).

Here's how to reproduce it:

1. Download this project: manipulating_shapes.zip
2. Run the main scene
3. Note the loading/initialization time
4. Open main.gd and change slow to false
5. Run the main scene again
6. Note the much faster loading/initialization time

[venilark]

I haven't tested it but do you think something like a CSGTorus used as an expanding ring/shockwave where an Area3D has to detect it, could severely impact performance? this requires the torus to change its collision shape every frame plus an Area3D to detect it, which I read it can be slow

[mihe]

A CSGTorus3D with use_collision enabled effectively becomes a StaticBody3D with a ConcavePolygonShape3D, which in itself is not ideal since you'd then need to enable the "Areas Detect Static Bodies" project setting for an Area3D to detect it, which can be a dangerous footgun as mentioned here.

If we ignore that part, it would probably depend somewhat on the tessellation of the torus, but just changing a single shape isn't going to have a massive impact. It's usually when you start doing many shape changes per frame that it becomes a problem.

[Zylann]

Just noting that this issue can be a big problem for construction games, where it is extremely common to have rigidbodies made of compound shapes that can be removed/added at runtime, as players construct or do damage to them (building, vehicle, ship...). Game examples include Robocraft, Starship Evo, Space Engineers, From the Depths, Scrap Mechanic...

[yosoyfreeman]

If we ignore that part, it would probably depend somewhat on the tessellation of the torus, but just changing a single shape isn't going to have a massive impact. It's usually when you start doing many shape changes per frame that it becomes a problem.

I been working on a character controller with a dynamic crouch and i found that manipulating the shape is the most expensive thing on the project right now. Manipulating around 16 shapes starts to affect the performance and with 32 or 64 the framerate slows down a lot. For comparison, doing this with Godot physics has no noticeable impact on the frame rate. This makes the achieving the feature parity with the old prototype using jolt is unfortunately not possible right now, as we were modifying the shape of dozens or even hundreds of collision shapes in a similar way to a bullet hell.

Is there any possibility to lessen the performance impact? Maybe not hundreds, but we would like to at least maintain the crouching for 32 players.

[mihe]

Manipulating around 16 shapes starts to affect the performance

1. How are these 16 shapes distributed? Is it 16 bodies each with one of these shapes?
2. Do the bodies have any other shapes in them?
3. Are you manipulating the shapes more than once per frame?

If it's 16 bodies all containing just a single shape that's being manipulated each once per frame I would be somewhat surprised, since a single-shaped body wouldn't be using Jolt's StaticCompoundShape, which is the expensive part of the rebuild that happens when you manipulate shapes.

There's not a whole lot that can be done to improve the situation in that scenario, besides maybe checking to see whether the shape data has actually changed before invalidating/rebuilding the root shape, but that'll only be viable for the simpler shapes, which are relatively cheap to create anyway (assuming it's the only shape in the body).

[yosoyfreeman]

Thank you Mihe.

I double checked and you are right, there is not a big difference. But updating 64 collision shapes is taking up to 8 ms now in godot physics or jolt. Which is estrange, this used to not be a problem some time at the past.