In the specific case of non-interpolated nodes, if ancestor nodes were moved on the physics tick this would lead to unnecessary NOTIFICATION_TRANSFORM_CHANGED and calls to VisualServer.

This would lower performance and lead to unwanted physics interpolation warnings about movement on physics ticks.

Here we remove these unnecessary notifications.

Fixes #103330
Relevant to #103232
Relevant to #103025
Relevant to #101823

Notes

• This problem does not occur when top_level is applied to the first non-interpolated node.
  But users can also choose to operate non-interpolated branches without top_level, so we want to make sure this works efficiently and correctly.
• I'll try and do some testing for regressions in existing demo games, but ultimately this (or whatever we chose to go with) will need testing in the wild.
• Stops the propagation as soon as the first non-interpolated child is found (using the same mechanism as top_level). This prevents physics movements on ancestors affecting the non-interpolated branch, but still allows the possibility of setting non-interpolated branch xforms directly on physics ticks.
• It will only affect projects that have non-interpolated nodes hanging from interpolated, so will not affect most projects.
• Fix also applicable to 4.x, I'll have a look at a PR there too.

UPDATE: Camera3D seems to work fine, it doesn't depend on NOTIFICATION_TRANSFORM_CHANGED. And teleportation should work, because non-interpolated nodes need to update their xform each frame anyway.

Discussion

An alternative way to prevent propagation of TRANSFORM_CHANGED into non-interpolated branches is to set the first non-interpolated node to top_level. top_level children already don't have transforms propagated to them.

This is indeed the approach I took in the primary use case for non-interpolated branches - manually interpolated Cameras. This is probably the reason why I hadn't seen these warnings and the potential for this problem before.

It probably makes sense to close this bug via this PR whether or not we go with using top_level or not for non-interpolated branches. 🤔

To elaborate, the first non-interpolated (3D) child of a moving interpolated node will always require some special treatment to work correctly. The reason is that if nothing else is changed, this child will judder on each physics tick because its render xform will be based on the physics transform of the parent.

Thus the child will usually either need to:

• Call get_global_transform_interpolated() on some target node (maybe the parent)
• or manually keep track of prev and curr xforms of a current node (similar to get_global_transform_interpolated(), but without the need for priming

In the longterm, t is not out of the question to possibly automatically set the first non-interpolated node as top level. But that would be for later PR / discussion.

Related

It is also just possible we could have a system whereby the first non-interpolated child automatically grabbed the client interpolated xform from the parent on each frame. But that's perhaps something to consider once we handle all the cases, IK, ragdoll and XR and see if there is a common code that can be consolidated.