RayCast3D debug visuals jitter and lag behind since 4.3

[Wyatt-Warren]

Tested versions

v4.3.stable.mono.official [https://github.com/godotengine/godot/commit/77dcf97d82cbfe4e4615475fa52ca03da645dbd8]

System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 (NVIDIA; 31.0.15.5123) - AMD Ryzen 7 3800X 8-Core Processor (16 Threads)

Issue description

When Raycast3Ds are moved, the debug shape jitters and lags behind. This happens when moved in any way. The amount depends on the FPS. The collisions seem to be unaffected.

Steps to reproduce

Create a Raycast3D and move it along side any other type of Node3D through any means. It is apparent if the Raycast3D is the child of the other Node3D because they should move in sync.

Minimal reproduction project (MRP)

racyat-test.zip This project displays a RayCast3D clearly lagging behind a CSGBox. There is a static body to test if collisions are consistent with the debug shape.

[smix8]

Because RayCast3D is a physics using node.

It updates its shape and instance transform with the physics tick that is not necessarily in sync with your frame rate so any visuals get just "normal" physics jitter.

Your animation is changing just the node position every frame while the shape position gets updated on every physics tick.

[Wyatt-Warren]

I understand, but the issue is I only started seeing this with 4.3. If you open the test project that I provided in 4.2 the effect is not there. Also in the project that I provided, the maximum FPS is set to 60 which is the same as the physics tick rate and despite this, the ray still lags behind it's actual position significantly, but only in version 4.3.

I should also add that you can clearly see that when the ray is jittering or lagging the ray goes between visually colliding and not colliding with the body, yet the actual collision, that being whether the body is displaying red or not, is not changing, meaning the visual is not matching the actual state of the ray.

[matheusmdx]

This seems to have started after #82599, compiling with this pr applied and the fix #90800 starts the desync

[smix8]

The only difference is that before, because a Node3D pushed all its transforms to all the children, it would show a false debug state, more so now with interpolation. The actual shape would move smooth as it would be updated twice, but it was also wrong half the time. The real physics shape was never in that position when it was not updated with the physics sync, it was a visual lie.

With the linked PRs the shape is only update when it is really updated and that reveals to users how physics actually does the update, it jitters just like physics always does because it is not necessarily in sync with the frame rate.

Going back to the old "smooth visuals" does not solve the issue because then you get the "why are my shapes not working, the visuals show they should collide --- yeah because the visuals are lying just to look nice" which is even more dog. If you move your RayCast3D node with the physics step your visuals are correct, everything else is just made up and you would need to force update the node to have the starting position correct. You still can not use an "idle" processing AnimationPlayer or process() function or anything else that is not in sync with physics to move the node.

What could be done is that the debug gets updated when users call the force_raycast_update() function in scripts as there is no code path that makes the debug react to anything there.