Reparenting frozen RigidBody3D breaks smoothing

[nanodeath]

Hi there. I have a CharacterBody3D character in my game that when they pick up a RigidBody3D, it static-freezes that object and reparents the object to the character, as well as adding the necessary collision-exclusion stuff. This mostly works, except for smoothing. The physics object itself will attach and move with the character as desired, which can be checked using Debug > Visible Collision Shapes, but the mesh stops moving with its parent object entirely.

Screencast.from.07-27-2024.08.15.02.AM.webm

In the above video, the left object is a normal cube, while the right object is using Smoothing. The expected behavior is that the mesh on the right will track the right collider, and generally look similar to the cube on the left. Both cubes reparent to the player after a 1 second delay.

SmoothingDesync.zip

And here's the repro project. Godot 4.2.2 + Smoothing 1.2.1. I've also verified it affects Godot 4.3-rc1 mono.

I don't have a workaround yet, but I was thinking of reparenting the mesh node depending on whether the item is being held. But also I don't really want to do that 😛

Thanks for looking!

[lawnjelly]

Sorry I took a while, I've been afk for a few days.

It looks like the problem is that on reparenting, you need to reset what the smoothing node is following. For convenience it automatically selects the parent node on _ready(), but you are changing the node path by reparenting after _ready().

The solution is to reset this nodepath by assigning the target again after reparenting:
$Smoothing.target = ".."

You may need to use a different script for the two different blocks in this example for it to work (as the control block doesn't have a smoothing node).

This could possibly be handled better by the addon, but not a great reason to change as core physics interpolation should be available soon even in 4.x (after 4.3).

[nanodeath]

Is the problem the target node_path is resolved to an absolute path at runtime?

[lawnjelly]

Is the problem the target node_path is resolved to an absolute path at runtime?

Yes, it does a few things like this for safety, should the node be deleted, if I remember right (I wrote it years ago).

[nanodeath]

The more I dive into this, the more interesting it gets 🙂 I think I see the problem.

The good news is _enter_tree is executing as expected when reparenting the object -- it's just the code isn't working the way we hope. And the culprit is...this line:

smoothing-addon/addons/smoothing/smoothing.gd

Line 144 in 0c4ae88

var parent = get_parent_node_3d()

During _ready, set_as_top_level(true) is called, which obviously sets the object as a top-level object:

smoothing-addon/addons/smoothing/smoothing.gd

Line 88 in 0c4ae88

set_as_top_level(true)

And we know _ready gets called after _enter_tree, because...in DOM terms, "enter tree" is called during the "capture" phase, while "ready" is called during the "bubbling" phase. That is, we call _FindTarget() (in _enter_tree) before calling set_as_top_level(true) (in _ready).

get_parent_node_3d is a little weird:

Returns the parent Node3D, or null if no parent exists, the parent is not of type Node3D, or top_level is true.
Note: Calling this method is not equivalent to get_parent() as Node3D, which does not take top_level into account.

(emphasis mine)

---

Basically, get_parent_node_3d will only ever work when the Smoothing scene is first created because it's called before top-level is enabled.

I think the solution is simply using get_parent. I'll test that out and sent our a PR for it if so.