Physic Interpolation on moved hidden object lock them on place

[TheMagnat]

Tested versions

• Reproducible in: 4.5.dev5
• Not reproducible in: 4.5.dev4 and below

System information

Godot v4.5.dev5 - Windows 11 (build 22631) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated AMD Radeon RX 6950 XT (Advanced Micro Devices, Inc.; 32.0.21001.9024) - 13th Gen Intel(R) Core(TM) i5-13600KF (20 threads)

Issue description

After having moved an hidden object (Here using a tween, I did not test with other type of motion) with physic interpolation on, if you show the object, it will lock it in place, and make it unable to move (at least with a tween, even if you kill and recreate the tween)

20250605-1017-04.5866615.mp4

This only happen in 4.5.dev5

Steps to reproduce

• Create a visible object A and hide it
• Move A with a Tween
• Unhide (show) A

(Using the MRP, you can just start the project and start the current scene, note that in the editor using a @tool script the bug does not appear. There is a second scene "bug_test_scene_2" showing the same bug but after the motion ended)

Minimal reproduction project (MRP)

PhysicInterpolationAndHideBug_MRP.zip

[lawnjelly]

Will take a look.

It may be the tween is not notifying the SceneTreeFTI that the node is moving (I tried to cover all the places that move the nodes, but but I might have missed one).

[TheMagnat]

Will take a look.

It may be the tween is not notifying the SceneTreeFTI that the node is moving (I tried to cover all the places that move the nodes, but but I might have missed one).

Little update, I did a little check and it also happened when the movement is caused by other source than the tween (like directly moving it in the script)

Here is the updated version of the script I used in the MRP ("bug_test_scene.gd")

bug_test_scene.gd.zip

[lawnjelly]

Ok I worked out that tween is not designed currently in a way that will work with physics interpolation, if it works already, it is by accident. 😁 Particularly calling a tween to move a value at intervals (rather than every physics tick) won't likely work well.

Physics interpolated objects should be moved on the physics tick

If you check the physics interpolation docs:
https://docs.godotengine.org/en/4.4/tutorials/physics/interpolation/physics_interpolation_quick_start_guide.html

"Make sure you move objects and run your game logic in _physics_process() rather than _process(). This includes moving objects directly and indirectly (by e.g. moving a parent, or using another mechanism to automatically move nodes)."

and again here:
https://docs.godotengine.org/en/4.4/tutorials/physics/interpolation/using_physics_interpolation.html#move-almost-all-game-logic-from-process-to-physics-process

The same problem is occurring in your second demo, if you change it to move the nodes on physics_process(), it works.
So the new optimization doesn't seem very resilient to this misuse currently, I'm sure I can improve this though. 👍

There may not currently be physics interpolation warnings for misuse here (these were previously spammed prior to 4.5 dev 3 in a lot of situations). I'll try and re-instate these with the new SceneTreeFTI as they are useful for prompting users to mistakes in usage.

Incidentally if you set it to legacy SceneTreeFTI mode (physics/3d/physics_interpolation/scene_traversal, it also works, so it does seem to be associated with the optimized method.

This is probably not too tricky to fixup, but it may have to wait until after weekend unless I can sneak it in. Until then, moving processing to physics tick is always a good idea, or using legacy mode temporarily if this bug affects you.

[TheMagnat]

Ok I worked out that tween is not designed currently in a way that will work with physics interpolation, if it works already, it is by accident. 😁 Particularly calling a tween to move a value at intervals (rather than every physics tick) won't likely work well.

Physics interpolated objects should be moved on the physics tick

If you check the physics interpolation docs: https://docs.godotengine.org/en/4.4/tutorials/physics/interpolation/physics_interpolation_quick_start_guide.html

"Make sure you move objects and run your game logic in _physics_process() rather than _process(). This includes moving objects directly and indirectly (by e.g. moving a parent, or using another mechanism to automatically move nodes)."

and again here: https://docs.godotengine.org/en/4.4/tutorials/physics/interpolation/using_physics_interpolation.html#move-almost-all-game-logic-from-process-to-physics-process

The same problem is occurring in your second demo, if you change it to move the nodes on physics_process(), it works. So the new optimization doesn't seem very resilient to this misuse currently, I'm sure I can improve this though. 👍

There may not currently be physics interpolation warnings for misuse here (these were previously spammed prior to 4.5 dev 3 in a lot of situations). I'll try and re-instate these with the new SceneTreeFTI as they are useful for prompting users to mistakes in usage.

Incidentally if you set it to legacy SceneTreeFTI mode (physics/3d/physics_interpolation/scene_traversal, it also works, so it does seem to be associated with the optimized method.

This is probably not too tricky to fixup, but it may have to wait until after weekend unless I can sneak it in. Until then, moving processing to physics tick is always a good idea, or using legacy mode temporarily if this bug affects you.

Oh my bad, I did not know that EVERY object (event those without any physic body) had to be moved inside the physic process too when physic interpolation was on.

However, if I understand well, the worst that should happen is that objects should have visible artifacts, here in this scenario the object become unmovable if it was hidden during one transformation, I don't know if preventing this would have an impact on performance with the new physic interpolation algorithm, but if not I think it should be done

Also as you said, warning when using classic process to update an object transform when physic interpolation is on are welcome since it would help people that don't read in deep (like me oops) but also could help transitioning older project to use physic interpolation

[lawnjelly]

Oh my bad, I did not know that EVERY object (event those without any physic body) had to be moved inside the physic process too when physic interpolation was on.

It's okay, a lot of people get confused here, this is a result of it being called "physics interpolation" where in reality it is nothing to do with physics. I vetoed this naming if it's any help. 🤷‍♂

It may be worth us modifying the docs / classref in future to drill this point down .. "the first rule of physics interpolation is, it is nothing to do with physics". 😆

There are exceptions of course, you can mark branches as OFF for physics interpolation, by using the physics_interpolation_mode in the inspector.

However, if I understand well, the worst that should happen is that objects should have visible artifacts, here in this scenario the object become unmovable if it was hidden during one transformation, I don't know if preventing this would have an impact on performance with the new physic interpolation algorithm, but if not I think it should be done

Yeah, don't get me wrong, it is a bug on my part 😊 , I likely built the logic making some assumptions here, but this won't happen sometimes, so I have to modify it to handle it gracefully.

The warnings are useful, also note there is now a debug traversal mode which will add extra logging info to aid in this way too, see #106244 for details (it is so new it's not yet in the docs).

UPDATE:
I've found the bug. It's because it is invisible, it isn't removing one of the flags during the scene traversal, and hence it thinks it is on one of the update lists after the list has been cleared, and is never getting an update. Will figure out the best way to fix. 👍

I haven't re-instated physics interpolation warnings in the PRs below, that will be for a separate PR (maybe next week).