Fix initial skin update timing in Skeleton3D

[TokageItLab]

• Revert/Follow up Move skin registration process into deferred on ready #97489 to move the process to ENTER_TREE from READY
• Fixes Reparenting the parent of an imported model stops the MeshInstance3D from skinning properly #97982
• Fixes Animation detach on scene change.  #98001

I have changed the update timing on the MeshInstance side in #97489 to READY, but now move it to the original timing as ENTER_TREE with calling deferred. Instead, we will update the skin once before the deferred process in the skeleton.

This means that notifications for updates are called twice only in the first frame; once in the normal process and once in the deferred process, but this is probably not a serious problem since it is managed by the update flag, which is separate from the dirty flag.

Also, confirmed that #97459 does not recur.

[TCROC]

We ran into an issue with this change but also found a workaround in our project. I'll break down what happens so we can discuss whether any changes should be made in this PR to account for this problem we encountered.

So in our project, we generate icons for user inventory items at runtime. We do this by equipping an item to the character, taking a screen capture (offscreen) of that item, and then displaying it as an icon like so:

Now the problem is, resolve_skeleton_path has been moved to call_deferred

godot/scene/3d/mesh_instance_3d.cpp

Line 336 in af77100

callable_mp(this, &MeshInstance3D::_resolve_skeleton_path).call_deferred();

This means the skeleton doesn't move right away to its location and I can't take a screenshot of it right after equipping it.

Which in turn looks like:

I found a workaround to be this:

foreach (var child in currentMesh.FindChildren("*", recursive: true))
{
    if (child is MeshInstance3D childSkel)
    {
        // Reassign the skeleton to itself so the skin has an immediate refresh
        childSkel.Skeleton = childSkel.Skeleton;
    }
}

This works because set_skeleton_path invokes resolve_skeleton_path right away unlike the new deferred call in notification:

https://github.com/godotengine/godot/blob/af77100e394dcaca609b15bef815ed17475e51ed/scene/3d/mesh_instance_3d.cpp#L211C1-L218C1

I propose a few possible solutions:

1. Is the reason for call_deferred for thread safety? If so, maybe we can use the call_threadsafe function?

2. Can we make resolve_skeleton_path public? This way I can just call currentMesh.PropagateCall("resolve_skeleton_path"); to make sure it gets invoked right away.

3. I just bite the bullet and stick to my workaround. This is my least favorite option... but it is an option 😅

NOTE:

I ran into this same issue with the BoneAttachment3D class. We use this class when we aren't using skeletons. I worked around it by manually invoking OnSkeletonUpdate after adding the item as a child.

[TokageItLab]

@TCROC

Is the reason for call_deferred for thread safety? If so, maybe we can use the call_threadsafe function?

This is probably fine. I thought I had a recurring problem with the #98001 project when I did that before, but maybe I had the wrong build binary.

I've made the change, so please test to see if it's a problem.

[TCROC]

@TCROC

Is the reason for call_deferred for thread safety? If so, maybe we can use the call_threadsafe function?

This is probably fine. I thought I had a recurring problem with the #98001 project when I did that before, but maybe I had the wrong build binary.

I've made the change, so please test to see if it's a problem.

Just tested. Everything goes back to working again! Thanks! :)

[fire]

Tests from developers work correctly.

[clayjohn]

Thank you!