Wrist rotation is incorrect

[geowarin]

Hello @cdoise-vbg and thank you for this wonderful script, it helped me tremendously!

I wanted to share with you a few observations.

I fixed the bone map you provided to include additional fingers:

Taking the animation synty_locomotion_masc/A_Idle_Standing_masc as an example.

Here is a picture of the first frame of the animation with the finger fixed applied:

Without the fix applied:

So the fix definitely seems to help.

However, here is how it looks in unity:

As you can see the wrist seems to be rotated.

Edit: looking at this more closely, the elbow seems to be rotated as well, maybe the whole arm?

[cdoise-vbg]

Thanks for giving this a try. If you need a quick way to make this usable for your specific case, you might be able to look at do_custom_animation_fixups method in the python script and add additional rotations for specific bones causing you issues.

In general, it seems there are some issues with roll/orientation of armature bones on different models that I need to figure out (not all armatures follow the same conventions - or are even self-consistent - with the directions the X/Z axes of the bones are facing on different limbs of the skeleton. For the sample models I was using in Godot there's some code in the script that modifies the animation track for the third finger of the right hand that can be turned off at the top. I'm not sure yet whether there's an issue with the actual animation data or if it has to do with the target armature setup vs what was used when those animations were created (was trying to solve for the lack of a t-pose rest pose).

[geowarin]

Thanks for giving this a try. If you need a quick way to make this usable for your specific case, you might be able to look at do_custom_animation_fixups method in the python script and add additional rotations for specific bones causing you issues.

Yes, I've read the script! I'm not in such a hurry, I'd rather work with you and try to find a good solution for this. :)

In general, it seems there are some issues with roll/orientation of armature bones on different models that I need to figure out (not all armatures follow the same conventions - or are even self-consistent - with the directions the X/Z axes of the bones are facing on different limbs of the skeleton. For the sample models I was using in Godot there's some code in the script that modifies the animation track for the third finger of the right hand that can be turned off at the top. I'm not sure yet whether there's an issue with the actual animation data or if it has to do with the target armature setup vs what was used when those animations were created (was trying to solve for the lack of a t-pose rest pose).

I'm tempted to say it's coming from the animation data. Here is the same animation retargeted on the mixamo Y-Bot model:

Obviously, the fingers not mapped on the bone map are crooked but also, you can see that the arm rotation is wrong here as well.

I noticed the feet rotation is off as well.

[geowarin]

Where it gets trickier is that godot includes a "rest fixer" in the import dialog for the skeleton, so the error could come from there as well.

This feature is not very well documented so it's difficult to say how it's working

[cdoise-vbg]

Thanks for the pointers. I was not aware of the Godot rest fixer. I'll try to look at that too.

I'm also hoping Synty will eventually release an update where their animations have T-Pose rest poses. Several people have requested that on their discord server. However, I'm still hoping to also figure this out myself to improve my own skills at working with animation data.

[geowarin]

I'm investigating. It seems that if I use the script on the armature directly in blender, then the animation looks correct.

So it is probably the way it's setup in godot that's causing the problem

[cdoise-vbg]

Thanks again for your efforts in investigating this. I'm probably not going to have much time to look at this for next week and a half, but then I'm planning on getting back into it. For what it's worth, I did get some extra twisted results from trying out the Synty Office pack characters in Godot with the animation output, and it looked like their bone orientations/rolls had a decent amount of variation in them.

[geowarin]

No problem. Take your time, you don't owe your time to anybody and your script has already helped a great deal 😄

I'll continue investigating and keep updating this thread.

What I suspect is that it is not practical to retarget the animations to any armature so maybe we should encourage people to use the armature that comes with the synty animation pack and then help them retarget the animations in godot

[geowarin]

I have worked on it a fair bit and I noticed a few other problems:

Running the script on multiple fbx sometimes lead to a vertex explosion:

I was able to solve the problem with this code:

def clear_and_reset_armature(armature):
    clear_animation_action_on_armature(armature)
    bpy.context.view_layer.objects.active = armature
    bpy.ops.object.mode_set(mode='POSE')
    for bone in armature.pose.bones:
        bone.location = (0, 0, 0)
        bone.rotation_quaternion = (1, 0, 0, 0)
        bone.scale = (1, 1, 1)
    bpy.ops.object.mode_set(mode='OBJECT')
    bpy.context.view_layer.update()

That I call after an NLA track is added and before another FBX load.

Another problem is that sometimes, the hips bone constraint is not correctly applied:

That seems to be fixable using LOCAL for the COPY_LOCATION but then, for some animations, the whole armature position is off.

I believe that can be fixed by using constraint.use_offset = True and applying the delta position between both hips bone to the root bone.
But that leads to the root bone not always flush with the ground.

And it messes up some of the root motion animations.

I've update my PR #2 with the changes but to be honest I'm a bit out of my depth here.

[cdoise-vbg]

I'm wondering if it might be better to reset to rest pose instead of setting everything to location 0 and resetting quaternion (which could give very odd results if there are any animations missing animation tracks for some bones). I'm also thinking this (directly copying rotations and locations) only really works with a target armature that has the exact same proportions. Otherwise, it's probably necessary to do something like copy the hip bone position, and then do rotations only for the other bones (assuming no stretching on the animation) plus maybe IK for hands and feet to target the hands and feet position on the source animation. We might be venturing off too far off into generalized animation retargeting (whereas my original goal was simply to get all of the existing animations to have a T-Pose on a skeleton with the same proportions). If the proportions of skeleton are the same, then it seems like world space should be working (minus issues of original bone alignment and rolls). It does seem like there might be a fair bit of variation on skeleton conventions for which way X/Z axes of bones are pointing, so perhaps worthwhile to forge ahead.

First week of October, I should hopefully be able to look at your pull request (but might be able to find some time later this week).