SoftBody3D broken in 4.5-beta1

[simpkins]

Tested versions

From a bisection, this appears to have been broken by #105901.
The code works properly in 2270224, and is broken in 0e9a59b.

System information

Windows 11, Godot 4.5-beta1

Issue description

SoftBody3D objects no longer appear to move properly. e.g., placing a SoftBody3D in space no longer falls to the ground normally due to gravity, but falls extremely slowly instead. With Jolt physics it appears to gradually slow down and very quickly stop moving entirely, while with Godot physics it continues moving, but much more slowly than it should.

I suspect the issue is due to recursive delivery of NOTIFICATION_TRANSFORM_CHANGED events.
SoftBody3D is sort of a weird class, and it tries to always keep its transform set to (0, 0, 0). It processes transform notifications for itself, and whenever its transform is changed it moves its soft body vertices, then resets its transform back to (0, 0, 0). It calls set_notify_transform(false) so that it won't be redelivered a new notification about setting its transform back to 0. However, after #105901, calling set_notify_transform(false) is no longer sufficient to disable transform notification, so it keeps receiving new notifications about the change it made.

Steps to reproduce

Open the attached project, and start the scene. The rigid body falls normally, while the 2 soft bodies only fall very slowly.

Minimal reproduction project (MRP)

soft_body_bug.zip

[lawnjelly]

Actually looking at it, I think we should just revert #105901 for now, and I'll have another look at how to reduce these in 3.x / 4.6 (it's not absolutely pressing) under a little less time pressure.

It looks like 4.x is relying on the NOTIFICATION_TRANSFORM_CHANGED from VisualInstances a lot more than in 3.x (where this was forward ported from), so there might be more regressions here.

...

The problem stems from VisualInstance requiring these notifications only when FTI is off. Derived nodes otoh are likely currently relying on this inherited request (when they should be making their own request).

Switching off the behaviour in a parent class (as allowed currently and used by SoftBody) is extremely hacky as it can break other mechanisms (as evidenced here).

The entire transform system for SoftBody is currently very badly thought out (imo) and needs reworking, this is something I discussed with mihe on RC, they had to do some bodges in Jolt because it wasn't clear how it should work (with relative and absolute xforms). Fixing SoftBody without causing regressions in child nodes will be interesting for someone in the future. 😁

https://chat.godotengine.org/channel/physics?msg=i9vYNaP4iuQYd427g