smix8 / godotanimationretargeting Goto Github PK

Add documentation that retarget_scale accounts for skeleton bone scale and not Spatial scale of parent nodes or the skeleton node itself (which is just a hidden spatial).

Moving AnimationPlayers with bonetracks is actually broken in Godot. The animationtracks are all renamed wrong. Related issues seem to be open for months and years without fixing.

The new auto-rename of the retargeting tool tries to fix this if child structure is different between source and target, e.g. if your animationplayer path is "TopNode/Skeleton/SubNode:bone" and your target animationplayer has "Skeleton/SubNode:bone" it will automatically try to adjust all trackpaths.

Currently this only works on child nodes with a subnode paths but does not work properly when the AnimationPlayer is moved to a parent or sibling level or the root is changed compared to the default after the skeleton asset import.

• Nodepaths for bones are relative to skeleton
• Skeleton is relative to AnimationPlayer root
• Root is relative to AnimationPlayer

Since all the returned Nodepaths could have plenty of added dots depending on parent and child position or resources a lot can go wrong and a lot of adjustments are required to make the renaming work more reliable.

Currently the retargeted animationtrack adds all missing bonetracks with a start and end keyframe to assure that the new animation will properly work inside AnimationTree with existing blendspaces and blendtrees.

Currently if your skelton has 40 bones but the original animation has only 8 bones keyframed the new animations would have all 32 missing bones as well with only start and end keyframe.

Technically to assure that your retargeted animation does not break only bones are required that are between two other keyframed bones in the bone hierarchy.

Filtering out the uncessary bones would cleanup the new animation and reduce the number of stored animationtracks.

Currently the tool can retarget single animations or the whole animation player. There should be an option to retarget only the new animations of a skeleton, and load them into the animation player much like Retarget Animation Player.

ex.
AnimPlayer 1:
//Dodge
//Punch
//Kick

AnimPlayer 2:
//Dodge
//Punch
//Jump
//Swing
//Climb
There are situations where you would want to only import the new ones. ex. batch imports, avoiding overriding the functions in the animation tracks

You can retarget the anims one by one, but it can get tedious with a large import.

I imagine it could work like "Retarget animation player", except it only brings over the new animations, so maybe "Retarget New Animations Only".

I'm attempting to bring over certain Unity animations, and wanted your input.
Basically, here are some animations.

Paired_PushShove_Att.zip

If you import it into godot, you wont be able to see anything, but if you play the animation player, the keyframes still contain all the rotation scale and position data: its just that there is no skeleton. The data is correct. For a better representation, import it to blender.

My thought is that since each node corresponds to a bone, and since the bones and nodes use the same rot,pos,and scale,
that it would be possible to copy these values into a new animation that corresponds to bones instead of nodes
(Basically, instead of retargeting from skeleton to skeleton, it would be "extracting" the data from the node keyframes, and putting them into an a new animation)
We would probably need a dictionary with custom mapping of the node/bone names, but I think its feasible.

My question is how doable do you think it would be to make a tool that could copy the data from these keyframes into a skeleton? Is it something that can be incorporated with this tool, or should it be its own thing?

I'm thinking of potentially building my own tool in GDscript using your addon as a basis for this idea, but I wanted your input. You've worked with godot animations more extensively than I have.
Take a look and tell me what you think.

Currently the retargeting requires that the two skeletons are similar in bone hierarchy while names can be different. Bone chains between source and target skeleton need to have the same number of bones, only additional leaf bones at the end of retargeted bones are allowed.

Complex skeletons, e.g. Genesis or Character Creation rigs, often have additional bones between the retargeted bones, e.g. twist bones for legs and arms, but if not both source and target rig share those bones the calculated bone transforms will always be wrong.

The retargeting process needs to make an additional pass and crawl through parent bones to find additional bones that could influence the transforms of the retarged bones.

Would partially solve issues like seen in #19 when retargeting from simple rigs to more complex rigs and vice versa.

Ideally, there must be a way to create a bone matching tool. Something like

for x in bone_names_1:
for y in bone_names_2:
if x.similarity(y) > .5
if "_l" in x and in y
if x.split("_l") and y.split("_l) .size() > 1 //Allow empty false
bone_list[x] = y

And this would create a little popup menu where you can edit the bones that the algorithm didn't get right. preset bone mappings will always be better, but I think this would be an interesting addition. Rokoko also has this feature, and its 90% accurate.

Also, whats your opinion on adding a bone renaming tool or a bone name conversion tool? Ideally, you would need a massive list to compare against, but even rokoko has that covered https://github.com/Rokoko/rokoko-studio-live-blender/blob/master/core/auto_detect_lists/bones.py

https://github.com/Rokoko/rokoko-studio-live-blender

Also, is there "loss" when retargeting constantly? ie do the animations get more and more inaccurate if I keep retargeting back and forth between skeletons? I would assume yes, but I wouldn't know if the "loss" is negligible.

Currently the 3 bone correction input fields for position, rotation and scale are shared for all bones.

If users change the selected correction bone the values stay visually the same but a changed input is correctly applied to the new bone. Changing back to an already corrected bone does not show the previous applied values so users need to memorize them.

The idea is to store all correction bone input in a correction bone dictionary. Iff a previous bone is selected again all input fields should update with the previous correction values. If the skeletons or current animation changes the correction bone dictionary needs to be reset.

Would fix usability issues seen in #19 video.

When using custom bone mapping, the retargeted animation either has incorrect naming, or something else is going wrong.
Video: https://youtu.be/9O3UsoxphxE
Steps to reproduce:
Enter a custom bone mapping for all bones, using two different skeletons with two different naming convenitions
Click retarget animations
The resulting animation has the names from the source skeleton, which is an issue because the new skeleton doesn't have those
bone names

Also, is there going to be a way to drag a file with a dictionary onto the retarget node so that people can use it without running the game? ( I know you can setup a dictionary in a file, then load using set_custom_bone_mapping())

Currently the retargting tool creates a copy of the source animation to keep all method, sound or property tracks intact.

In the next step the tool is changing the keyframes of existing bones and adding filler tracks for missing bones.

Since Godot is by default not very supportive with animation iterations and (re)imports, e.g. from Blender, a requested feature is an option to keep all the non Animation.TYPE_TRANSFORM tracks of the target animation.

This way users could reimport their updated animations to Godot and transfer the animation keyframes to their existing animation tracks without rebuilding the added tracks from scratch.

EDIT:
Ideally would add a filter menu for tracks but the current user interface does not really support this

AnimationRetargeting is used by all user levels, from beginner to advanced but especially beginners feel at little overwhelmed with compiling Godot from source with the module.

The full feature set is impossible as an addon due to performance restrictions, addons are just to slow.

The idea is to create a simplified addon version with less features in GDScript. This version would have all the normal editor features that are not time sensitive. E.g. baking retargeted animations would be available even if it would take many seconds while freezing the editor. Features that require immediate updates like runtime retargeting or correction preview wouldn't be included.

EDIT:
I don't have an eta for this, could be a couple days or months.

The retargeting tool has no way to notice scaling that is not part of the skeleton bones.

This means if someone scales a parent spatial node or the skeleton node the retargeting tool will apply position offsets calculated with the bone rest pose at the original scale and not the final scale seen in the editor.

Changing scale of skeletons is something that you should avoid in general (works really bad for physics bones) but sometimes it can't be avoided or you just want to use some scale broken internet resource for a quick prototyp.

The idea is to add a property field for a scale multiplicator so the retargeting tool can up or downscale the position values accordingly.

Required retargeting data is currently always calculated when start_retargeting() is used (or editor button pressed).

While not very noticeable in the C++ module this can add a lot of additional processing time on the slow GDScript version.

After the first retargeting the data does not really need to be recalculated as long as:

• both skeletons (paths) stay the same
• mappings are not changed
• no user code from outside changes skeleton rest poses

A skip for (re)calculating offsets after the first retargeting and only reset when something changes could improve performance, especially for GDScript.

Technically reopening #3. So the consensus was that extremely small skeletons shouldn't really be used to retarget values because of the small values, but I noticed that retargeting animations from even a regular sized model a large model still caused the issues in #3. Seemingly, if the size difference is too great, there are issues with the animation ex. small -->big, medium --> big and vice versa. This time the skeletons are fully transformed to their respective sizes(Not scaled, but natively 10x and so on) On skeletons of similar proportions, the tool is pretty much flawless, but like this, not so much.

I bring this up because I found that Rokoko Retargeting does not have this issue(blender addon). It can retarget anims of any size, with no error/almost nil error. It is written in Python, so I don't know if the code may be useful in potentially solving this issue, maybe contrasting the methods of retargeting since it is similar to gdscript? It made me think that there's got to be something missing that could probably help.

https://github.com/Rokoko/rokoko-studio-live-blender/blob/master/operators/retargeting.py
https://github.com/Rokoko/rokoko-studio-live-blender

I don't think this issue is too major, but I do think its worth mentioning and leaving open for the time being. Ideally you won't be retargeting anims of this nature, but if this problem could be solved, it would speed up certain workflows ex. importing an animation directly into godot and retargeting, as opposed to the route of importing to Blender, scaling and retargeting, exporting from blender, and retargeting again. Importing various animations into godot, sometimes the skeletons are just by nature of different sizes, which is why, if ever solved, it would be a nice fix.

The sample project has a medium animation
and a small animation. Retargeting either to the massive skeleton causes aerial leap. Also, retargeting an anim to the smaller skeleton causes an even weirder aerial leap. The large skeleton has no anim by default.
ARBug.zip

Also a little more documentation on correction mode would be helpful. I used to be able to get it to work, now I don't know if I am doing something wrong. Even with correction mode though, it may help with the general positioning of the node, but it doesn't necessarily get rid of minor imperfections ex. foot placement etc.

Again, not priority, but if this tool could handle this problem, it would surpass rokoko and become #1 retargeter given enough time and speed up godot workflow.

Animation resources are often found with root/hip movement recorded with motion capture or authored and not always with the intention for actual useable root motion but just leftovers. Those animations don't work well with blending inside the AnimationTree or for game projects that require responsive, non-sluggishness movement controllers.

Idea is to add a new' retargeting option that fixates the animation by canceling all horizontal movement applied to the root/hip bone.

By default after the retargeting process is finished the same animation id is played from a saved playback position.

While this was done for runtime retargeting to not restart animations it makes it hard to compare two retargeting results inside the editor when source animation and retarget animation play at different playback positions.

The new option should reset both animations and start them in sync so if both skeletons are placed on top of each other small differences can be spotted more clearly.

I'm building now to test and looking forward to trying out your module. Please consider moving your files for the module to /. This allows us to update the module directly within our godot tree.

Thanks

First off, absolutely love the module! Thanks! But, as per usual, first bugs I encountered.

Problem: Retargeting gltf animations causes the new animations to have floating feet, and be slightly messed up.
Settings: Godot 3.3, Using 2 of the same skeleton, exported as gltf, different animations. Retarget bone rotation enabled, custom rig types.
Settings and Solution Attempts: Have tried all the settings in different combinations, but no avail D:.
Observations: It looks like, (I could be wrong), that the retargeted animations are all based around the hips. I wonder if this is causing problem?

File for reference
Animation Retarget.zip
Also video for reference: https://www.youtube.com/watch?v=ZggDMIXDHEw

This issue is minor in some cases, but in more extreme animations ex. longer punches, or longer leg movements, this problem becomes more extreme

Steps to Recreate:
Import two gltf rigs, retarget animation from 1 model to the other, and the resulting animation has messed up feet.

I will note, that when I retargeted a mixamo to mixamo rig, everything worked fine. The mixamo rigs were also the exact same skeleton, and the same scale. The skeletons above are different scales, despite being same size(I increased the node scale for reference)

Thanks once again! This project is a huge help for a lot of people, and I'll do my best to keep reporting bugs!

Currently rootmotion only works when both skeletons have the root bone as the first (root) bone in the skeleton.

If one skeleton has root motion on the first one, e.g. mixamo hip bone, and one skeleton has a static root bone with a moving, second hip bone retargeting the source hip to the target hip wouldn't work.

A custom mapping can not solve this issue because all positions are relative to the root and one is moving while the other is not. Also Godot forces bones to start at the end position of their parent bone so the static root bone length and orientation needs to be considered as well.

This would partially fix issues seen in #19

@smix8 Can you please share why this is not as Godot Addon?
I have seen other addon register a new Node Type. Is this a performance issue that we are not aware of?

Hello, I have two characters with animations (Godot_Chan_Stealth_Shooter.glb and Mixamo_POLYGON_Guy_Naked.dae) and I wanted to retarget all animations. I used a custom dictionary, but I get a weird result:

Please have a look at my project. Is there a way to fix this or am I doing anything wrong?
New Game Project.zip

I currently have a mixamo rig and animation that I'm attempting to map onto a character creator 3 rig. I'm getting unexpected results and have recorded a video to show my setup and experience with the plugin. Can you help me figure this out?
Thanks

https://www.youtube.com/watch?v=1mF-NvNctyw

Here is a minimal zip with both characters in godot, as well as the original fbx files if you want to look in blender or reimport (for test_npc, convert to glb in blender before reimporting into godot).

https://we.tl/t-g8zr0oUZW0
(Link expires in 1 week)

Also, It seems to me that the common rigs and mappings should be included by default as they are developed, though I'm sure that will take time. Common rigs include mixamo, epic skeleton, character creator 3, among others.

commit c2360db

I'm retargeting MocapOnline (www.mocaponline.com) to makehuman models and it won't work, now I forked it to show the changes so I can get help to fix the problem

Thank You for sharing such a nice and awaited feature

Description of the issue :
Currently it seems that it doesn't support Android
It doesn't let change "Animation Export Directory" of the "Animation Retargeting" Node from res:// which is not accessable when exported to Mobile Platform

Both Godot 4.x versions are broken due to recent core changes made in Godot 4.x.

Animation data changed:

• Animation Transform Tracks are removed
• Replaced by new, dedicated Tracktypes for bone origin, basis and scale
• and more ...

Skeleton changed:

• Changed the bone rest calculation completely.
• Skeleton bone positions are now imported in bone space
• Bones are no longer relative to bone rest.
• and more ...

Also a more official proposal for animation retargeting in Godot now exists by a core dev that superseded my proposal. This means addon development for the Godot 4.x is discontinued since there will be an official implementation.

I'm using RamsterZ animations (https://www.ramsterzanimations.com ) with makehuman and it won't retarget

Add a new option to retarget the root/hip bone position only for rootmotion even if retarget_position is turned off. By default retargeting the root/hip is unwanted as it can add small precision errors that cause a ripple and jitter to other bones depending on the skeleton (scale).

While rootmotion in Godot (and in general) has plenty of practical issues this doesn't mean that it shouldn't get retargeting supported at some point.

Currently several functions check AnimationPlayer.get_current_animation() to e.g. start playback or find the animation to retarget. This function returns an empty String if the animation is not playing rightnow or has ended and is not looped. Since the Inspector in Godot also bugs out on all input field while an animation is running this creates the annoying requirement to constantly stop and start animations manually for retargeting.

Changing to AnimationPlayer.get_assigned_animation() makes it easier as this function also returnes the previous running animation if playback is stopped. It still requires that the animation was loaded and started ones in the AnimationPlayer. If in the editor the animationtrackeditor panel must be opened ones to set an assigned_animation.

There are a lot of compatibility issues with the latest version of Godot's master branch.

SkeletonIK updates the entire skeleton bone chain on each frame. This can pile up to heavy performance costs on more complicated skeletons with multiple characters on the screen.

Often SkeletonIK is used not because it is necessary or it is a performance wise choice but because it is more convenient over (re)importing animations or setting up proper pose blendtrees.

Since IK chains in Godot are exclusive to each other the idea is to add another Nodepath for a SkeletonIK node. When IK bake is enabled it loops through the current animation track and reads the resulting transforms after ik is applied to write them as keyframes.

Work on a GDScript version has shown that an icon is required by Godot cause the class register would complain if no valid icon is set when registering the addon.

I am not an icon designer so if anyone feels like it and wants to create an icon for this module/addon go for it.

Basically, if the retarget mode is set to current animation, it doesn't actually do anything. It exports an animation player with nothing in it, and thats it. However, using retarget mode "animationplayer" exports ALL the animations, including the retargeted animation. Easy fix, but just a bug.

Steps to reproduce: retarget animation with retarget mode current animation set, and nothing will happen/empty animation player will be created.

Video: https://youtu.be/d35Vyxu3P34

Place to track all planned or requested features.

• #9 Add option to keep all non Animation.TYPE_TRANSFORM tracks from target animation
• #12 Add Android Support
• #17 Add option to bake SkeletonIK results to animation
• #18 Filter unnecessary bone tracks from new animations
• #21 Add target bone selection for rootmotion retargeting
• #22 Add transform compensation for additional bones in bone chains
• #27 Add match bone tool