Jolt Physics: Generic6DOFJoint3D - Unexpected movement between Rigidbodies depending on velocity

[MuggoMX5]

Tested versions

v4.4.1.stable.official [49a5bc7]
v4.5.dev5.official [64b0990]

System information

Godot v4.4.1.stable - Windows 11 (build 26100) - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 SUPER (NVIDIA; 32.0.15.6094) - 12th Gen Intel(R) Core(TM) i5-12500 (12 threads)

Issue description

I'm working on a racing game and my car is made up of 5 Rigidbodies (one for the car's body and of course four wheels) which are held together by four Generic6DOFJoint3Ds. When upgrading to Godot 4.4.1 I removed the Godot Jolt plugin and switched to the integrated Jolt physics. Now the wheels don't stay in place anymore, their position changes depending on the velocity of the car. They move forward when accelerating, sideways when turning and down when jumping.

You can see the problem here:
https://github.com/user-attachments/assets/7af56c25-1241-43e2-b6d3-2b5f7cbb78c1

It works like it should when I reinstall and enable the Godot Jolt plugin:
https://github.com/user-attachments/assets/00d84de3-7f66-4bc4-8744-1ee281d38ec8

Steps to reproduce

Run the MRP, drive the car with the arrow keys and you will see the issue.
Install Godot Jolt from the AssetLib, select "Jolt Physics (Extension)" under Project Settings -> Physics -> 3D and restart Godot.
Run the Project again and the car will behave as it should.

Minimal reproduction project (MRP)

Generic6DOFJoint3D Test 4.4.1.zip

[mihe]

This seems to be related to the fact that you're childing a RigidBody3D (the wheels) to another moving object (the car), which is known to cause all kinds of weird problems, since you effectively end up setting the transforms of the wheels every single frame, as a result of their parent node moving.

This is vaguely mentioned in the documentation as being problematic, even for Godot Physics, although the manifestations of these problems seems to be different for different engines:

Note: Changing the 3D transform or linear_velocity of a RigidBody3D very often may lead to some unpredictable behaviors.

It should really be spelled out more clearly in the documentation that you should not child a RigidBody*D to a constantly moving object, like another RigidBody*D.

A quick fix in your case is to add a script like this to your wheels:

extends RigidBody3D

func _ready() -> void:
    top_level = true

That'll allow you to keep the parent-child relationship, but the moment _ready gets called (i.e. when the wheels are added to the physics simulation) they become top-level nodes, which means they won't have their transform changed by their parent anymore, and will only be controlled by the joint.

You can also just restructure your nodes so that the wheels are not childed to Car of course.

With all that said, this of course doesn't explain the discrepancy between the extension and the built-in Jolt module, which is a bit odd, and might warrant looking into further.

[MuggoMX5]

Thank you very much for your help! Both of your solutions work fine with the MRP.
I wasn't aware I was doing something wrong and somehow always assumed, that only the joint would manage the position and rotation of node_b.

[eSavag]

Thank you both - mike's solution also helped with my similar issue. +1 to a stronger warning in the documentation!

[mihe]

With all that said, this of course doesn't explain the discrepancy between the extension and the built-in Jolt module, which is a bit odd, and might warrant looking into further.

I decided to do some bisecting to find out where this discrepancy came from, and it seems to have appeared as a result of #100983, which changed things around a bit, like how bodies register to have their state synchronized with the rest of the engine.

However, in a weird twist it seems I wasn't actually able to reproduce this issue on latest master anymore, because it turns out that #107454 somehow undid this particular discrepancy, at least within this specific MRP.

I can't make much sense of why exactly #100983 caused this change in behavior, and even less so why #107454 changed it back, but I have to assume that whatever feedback loop that's caused by continuously setting the transforms of the wheels is somehow sensitive to the order in which the bodies are added to the simulation, since that's the only thing that #107454 really could have changed.

Anyway, just to be clear, you should still not child a RigidBody3D to another moving node. That will still cause all kinds of weird problems. I'll try to make the documentation clearer instead.