Closed stryker313 closed 2 years ago
Blender has more precision with small float values compared to Godot.
Godot does use a lot of low precision floats and sometimes even clamps certain values behind the scene so a certain loss of precision has to be expected when multiplying small values with a scale factor. That is why I advice people to bring their skeletons and animations to the same scale in an external tool like Blender before importing to Godot. This way the source of multiplication errors is smaller when retargeting to different characters.
The Godot engine has pages of bugs reports to due to precision problems with e.g. margins, cause between 0.001 and 0.00000001 there is a clear difference especially if you multiply the values. That is one of the core problems. I don't think I can do much on this as I stick with the containers that Godot's animation system is using but if someone knows better let me know what to do to remove more of the errors.
Also a little more documentation on correction mode would be helpful.
I will see what I can do, no promises cause I am superbusy at the moment. UnfortunatelyI for this addon I started with a new day job and large project work so not much spare time left to work on the addon for the time being.
Ahh I see. I guess I will stick with the current rokoko/smix8 retargeter workflow for now. It was worth bringing up anyways. Good luck with your new job! Hope it pans out well!
@stryker313 You can also try to disable asset compression for mesh and skeleton bones on asset import in Godot. This keeps the information in a 32 bit float with more precision. The default import setting squeezes the information into a 16 bit float.
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.