Godot 3.5 rc2 - objects using RigidBody's global_transform.origin (or it's children positions) are lagging in display

[Yarwin]

Godot version

3.5 rc2

System information

Kubuntu 20.4, GLES3, R5 2600, AMD Radeon RX 5700 XT (navi10, LLVM 14.0.1, DRM 3.41, 5.13.0-41-generic)

Issue description

I'm using the Rigidbody's children positions (global_transform.origin) to change other objects positions – it's child Spatial (set as toplevel) and some another independent Rigidbody.
Expected outcome: objects that copies Rigidbody or it's children positions have their positions properly updated.
Result:
Video clip 1 – spatial

2022-05-29_02-00-04.mp4

Video clip 2 – RigidBody

2022-05-29_03-07-41.mp4

Steps to reproduce

1. Create Rigidbody with position3D as a child

2. Change the Rigidbody's position using _integrate_forces (by state.set_… and/or add_central_force)

3. Create spatial that copies said position3D's global_transform.origin in every physics frame or create rigidbody that uses said position as a target for transformation

4. Enjoy the lag

Setting physics/common/physics_interpolation has no effect. Moving Spatial's update to "process" instead of "physics_process" results in expected smooth movement. With proper speed and collision shape I'm also able to clip through the some RigidBodies (or their meshes) (instead of colliding with them - see the 2nd video clip).

Minimal reproduction project

3.5-one.zip

[Calinou]

Related to #37702. Can you reproduce this after switching to GodotPhysics as the 3D physics engine in the Project Settings?

With proper speed and collision shape I'm also able to clip through the some RigidBodies (or their meshes) (instead of colliding with them - see the 2nd video clip).

This is due to #9071. Increasing Physics FPS or using thicker collision shapes can help alleviate this issue.

[Yarwin]

@Calinou sadly I can. With GodotPhysics set as physics engine inphysics/3d/physics_engine property and 60 FPS I'm still experiencing the very same issue.

Here are the videos from my project:
Spatial:

2022-05-29.12-53-57.mp4

RigidBody:

2022-05-29.12-55-14.mp4

[Calinou]

@Yarwin Remember that for GitHub video previews to work, you need to have a blank line before and after the video URL. I edited your post accordingly, but remember to do this in the future 🙂

[Hiiamwilliam]

If you want a Node A to have the exact same Global Transform of a Node B, check RemoteTransform.

I think the problem is also a result of how the code is written. It expects one order of processed events, but the actual order is different. Expected:

1. _physics_process (MainRigid);
2. _integrate_forces (MainRigid);
3. _physics_process (Spatial [child of MainRigid]);
4. _physics_process (Spatial [root]);
5. _integrate_forces (RigidBody2).

Where steps 3 and (4 and 5) are interchangeable. If this was the order, no lag would be expected (given the Physics Engine also had no delay). In reality, however, the order is (according to print statements):

1. _physics_process (Spatial [root]);
2. _physics_process (MainRigid);
3. _physics_process or _process (Spatial [child of MainRigid]);
4. _integrate_forces (MainRigid);
5. _integrate_forces (RigidBody2).

I'm not sure if the printed order is trustable! Assuming it is, even if the Physics Engine had no lag, the result would still be laggy. I imagine _process uses updated Transform information, which is why using _process instead of _physics_process works with no lag on the Spatial.

Note: the documentation says you shouldn't set_linear_velocity (on RigidBody2) every frame (I don't think this is the root of the problems though).

[Yarwin]

It seems that @Hiiamwilliam is correct (thank you!) after setting up proper signals (one in MainRigid at the end of integrate_forces, one in Root in physics_forces and finally one in integrate_forces of RigidBody2) and yields the target position is being updated correctly (although there are still problems with #37702, as Callinou mentioned).