Foot L/R and Ball L/R bones have odd rotation when imported into UE 5.1

Hello, I'm noticing a small glitch, not sure if this is technically an issue with this addon or if it's more to do with UE5.1 The issue is that when I import a baked Manny anim from Blender (using UE-to-Rigify), the foot and ball bones end up with odd rotational key frames at the beginning and end of the animation sequence. To reproduce: -Use Manny template to setup Ue-to-Rigify -Animate the Rig (the foot/ball deformation happens no matter what the animation is) -Bake the animation back to the UE based Rig -Import the animation to the SK_Mannequin skeleton in UE 5.1 -The Foot R/L bones will have overdriven X rot at beginning and end of sequence, and Ball R/L bones will have Z rot issues.

The Skeleton will not show any odd rotations after baking in Blender, this only appears after importing to UE5.1 Have tested with Blender 3.4 and 3.5

can you confirm that the importing animations have been assigned the proper mesh reference in the "retarget source" property in asset details panel? (step 5 in the "adding retarget source" section of the linked guide). Retarget Source option tells the engine, which skeletal mesh was the animation created on, because by default I think Quinn is used. I might be wrong in this assumption, I haven't used been messing around Manny/Quinn animation assets a while.

Thanks again for the reply Sir! Right now I'm using the base SK_Mannequin to drive these animations, so there isn't any retargeting going on when seeing these distortions -I'm importing a Baked FBX from Blender -I'm choosing the SK_mannequin skeleton. Everything looks correct except for the L/R foot and ball bones, and the weapon_r bone The bones have animation keys driving them, but at some point in the animation, they will rotate 90-180 degrees on one axis.

[image: image.png]

On Wed, May 24, 2023 at 4:42 PM Grzegorz Muszyński @.***> wrote:

can you confirm that the importing animations have been assigned the proper model in the "retarget source" property in asset details panel? (step 5 in the "adding retarget source" section of the linked guide https://docs.unrealengine.com/5.0/en-US/retarget-manager-in-unreal-engine/). Retarget Source option tells the engine, which skeletal mesh was the animation created on, because by default I think Quinn is used. I might be wrong in this assumption, I haven't used been messing around Manny/Quinn animation assets a while.

— Reply to this email directly, view it on GitHub https://github.com/gzmuszynski/UE-to-Rigify/issues/3#issuecomment-1561899391, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7WH3DQQYVJ76NQXNOMB3WDXHZXDDANCNFSM6AAAAAAYNUVHX4 . You are receiving this because you authored the thread.Message ID: @.***>

What you're describing is unrelated to my question (explaination below). Have you tried the option I mentioned? The attached image does not display, there might have been some error with replying to github thread via email.

Long explaination below:

The manual Retargetting Unreal's offering (The "Retarget to another skeleton" option when you right click on animation or skeletal asset) is to bind Animation asset to another Skeleton (where bone hierarchy might differ). Binding the Animation Asset happens at import, where Unreal asks to select a Skeleton. It's done at asset creation time. It's okay that you haven't done it to assets in question. I suspected as much.
However, there's another retargetting system that Unreal is running, where Animation asset is adjusted to each Skeletal Mesh sharing the same skeleton (Which means, that the bone hierarchy is the same, only transformations differ). This is automatic process that happens at runtime, and asset creator might not even know it's happening. This needs to happen, because different Meshes might share the same bone hierarchy, but they might be offset, relative to the skeleton asset. This is necessary step for Unreal to share the same skeleton for multiple characters, even if their proportions are different. In order for unreal to figure out which Mesh's Ref Pose should be used when calculating animated pose, the "Retarget Source" needs to be set to the Mesh the Animation was created on.

Those two systems are separate, and only share common name (which is unfortunate, because it creates confusion)

What I suspect is happening in your case is that the Skeleton asset has different Ref Pose (bone transforms) than the Meshes you're trying to display your Animation on. And because Unreal doesn't know which Mesh the Animation asset was created on, it defaults to Skeletal Ref Pose. This creates improper transformations for bones, because Unreal stores bone transformations in animations in relative space.

So I'm asking about the Mesh Retargetting system (latter), while your answer touches the Skeletal Retargetting (former).

Perhaps I'm using this tool in the wrong way, or making some assumptions about its operation? I hear you on all those points, and I think maybe I need to do a better job at communicating the issue I'm having. This issue appears to be specifically with how the IK bones (and weapon_R) are being baked using UE2Rigify. Those bones specifically look as though there is a random noise to rotation channels, like they are overdriven, or baked from the wrong source?

To better explain my situation- I'm animating in blender, and importing into UE5.1, using the same exact SKM/skeleton asset. The distortions are not only happening at runtime, you can see them in the animation sequence window (with the correct retarget source asset) To test in order to isolate the issue i did the following- -I added keyframes for loc/rot/scale with no change (still figure) to the rigified Manny in Blender, and baked that action using UEtoRigify. I then exported that FBX animation asset and imported into UE5.1, selecting the same skeleton that SKM_Manny is using (and what I'm using in Blender) After importing, if I preview that animation by opening the sequence window, the hands, feet and weapon bones have a weird wiggling animation (all other bones are static as would be expected)

If do the same step in blender, without using the plugin the issues doesn't appear-- Adding keyframes with no change to the SKM manny (no rigify process), exporting and importing to Unreal to the same skeleton using the same method, the weird wiggling hands/feet/weapon bone keyframes do not appear.

If it helps, I had put in a issue recently, where you helped me out, adding a "bake every bone" feature to this addon. I think that there is something in that feature update that is causing this weird random rotation? Every other bone works fine using your tool, except for the IK bones that are baked using that "bake every bone" feature.

Hope this makes the issue more clear? I tried attaching a photo in case that works. I appreciate the help on this, the tool has been so crucial for my workflow!

On Thu, May 25, 2023 at 1:28 PM Grzegorz Muszyński @.***> wrote:

What you're describing is unrelated to my question (explaination below). Have you tried the option I mentioned? The attached image does not display, there might have been some error with replying to github thread via email.

Long explaination below:

1.

The manual Retargetting Unreal's offering (The "Retarget to another skeleton" option when you right click on animation or skeletal asset) is to bind Animation asset to another Skeleton (where bone hierarchy might differ). Binding the Animation Asset happens at import, where Unreal asks to select a Skeleton. It's done at asset creation time. It's okay that you haven't done it to assets in question. I suspected as much. 2.

However, there's another retargetting system that Unreal is running, where Animation asset is adjusted to each Skeletal Mesh sharing the same skeleton (Which means, that the bone hierarchy is the same, only transformations differ). This is automatic process that happens at runtime, and asset creator might not even know it's happening. This needs to happen, because different Meshes might share the same bone hierarchy, but they might be offset, relative to the skeleton asset. This is necessary step for Unreal to share the same skeleton for multiple characters, even if their proportions are different. In order for unreal to figure out which Mesh's Ref Pose should be used when calculating animated pose, the "Retarget Source" needs to be set to the Mesh the Animation was created on.

Those two systems are separate, and only share common name (which is unfortunate, because it creates confusion)

What I suspect is happening in your case is that the Skeleton asset has different Ref Pose (bone transforms) than the Meshes you're trying to display your Animation on. And because Unreal doesn't know which Mesh the Animation asset was created on, it defaults to Skeletal Ref Pose. This creates improper transformations for bones, because Unreal stores bone transformations in animations in relative space.

So I'm asking about the Mesh Retargetting system (latter), while your answer touches the Skeletal Retargetting (former).

— Reply to this email directly, view it on GitHub https://github.com/gzmuszynski/UE-to-Rigify/issues/3#issuecomment-1563262943, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7WH3DVG4CMGYPTFUXGJDOLXH6JDXANCNFSM6AAAAAAYNUVHX4 . You are receiving this because you authored the thread.Message ID: @.***>

weird wiggling animation

Do you mean random jitter when playing animation? At work we found that certain rotations of the spine will export with microjitters. My assumption was that because there is a Quaternion to Euler conversion (two common way of representing rotations) somewhere down the Rigify pipeline, Send-to-Unreal or UE FBX importer will introduce gimbal locks that manifests as seemingly random jitter. Unfortunately that's something I haven't found solutions for. My workaround for this is to export the animation from unreal back to blender, fix the bones manually without using rigify and reimport. This doesn't get rid of the jitter per se, but minimizes it to acceptable range.

Yes this sounds like the issue I'm experiencing The jitter is odd, it is random in its occurrence, but not in its values? It doesn't look like noise (keys in a random value every frame), the values follow a curved expression. For instance the foot will be animated as expected, and then it will rotate 180 on what appears to be a smooth bezier action (if viewed on a anim graph). Not sure if you are able to access either this attachment or google drive link, but it's a zipped blender file with one FBX loaded that contains an animation with this "jitter" (exported from UE after bringing it in from Blender/UE2Rigify). The Foot_L bone starts and ends in the correct position, but the rotation frames quickly amp up into a parabolic curve that the foot spins around 360, it's so strange!

https://drive.google.com/file/d/1S-FuBbrZ4T3yiFUnOJGMmZE9rtShvPCw/view?usp=sharing

On Fri, May 26, 2023 at 2:55 AM Grzegorz Muszyński @.***> wrote:

weird wiggling animation

Do you mean random jitter when playing animation? At work we found that certain rotations of the spine will export with microjitters. My assumption was that because there is a Quaternion to Euler conversion (two common way of representing rotations) somewhere down the Rigify pipeline, Send-to-Unreal or UE FBX importer will introduce gimbal locks that manifests as seemingly random jitter. Unfortunately that's something I haven't found solutions for. My workaround for this is to export the animation from unreal back to blender, fix the bones manually without using rigify and reimport. This doesn't get rid of the jitter per se, but minimizes it to acceptable range.

— Reply to this email directly, view it on GitHub https://github.com/gzmuszynski/UE-to-Rigify/issues/3#issuecomment-1563893799, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7WH3DWW7TM5ACCDW5P3FL3XIBHUTANCNFSM6AAAAAAYNUVHX4 . You are receiving this because you authored the thread.Message ID: @.***>

I got your file. And yes, that looks exactly like gimbal lock curves would. Because blender takes any arbitrary rotation, this doesn't pose an issue until it's either baked, exported or imported. Then it tries it's best to recreate the curve in euler (yaw, pitch, roll) rotation, [0, 360] range. But because the original animation had either negative angles, or greater than 360, it automatically wraps around. That causes angles to go from something like 1 deg to 359 deg, and that's interpreted as a 360 degree rotation, instead of treating it like a 2 degree turn (shortest possible path in a ROM of that axis). Unfortunately, that's an issue with either Epic's blender tools, Blender as software, or Unreal's FBX importer. Nothing I, as a template provider, can do about. As it is now, I couldn't track down when in the pipeline the error is introduced.

The only solution I can give you is to manually fix the curve keys whenever they spit out this error

It is very helpful to understand the issue more clearly, totally understand that this is out of your control! Regardless this gives me a good perspective on next steps to get things working better on my end.

Thanks again for your time to take a look Grzegorz! Will be sure to mark as solved Best Milton

On Fri, May 26, 2023 at 11:49 AM Grzegorz Muszyński < @.***> wrote:

I got your file. And yes, that looks exactly like gimbal lock curves would. Because blender takes any arbitrary rotation, this doesn't pose an issue until it's either baked, exported or imported. Then it tries it's best to recreate the curve in euler (yaw, pitch, roll) rotation, [0, 360] range. But because the original animation had either negative angles, or greater than 360, it automatically wraps around. That causes angles to go from something like 1 deg to 359 deg, and that's interpreted as a 360 degree rotation, instead of treating it like a 2 degree turn (shortest possible path in a ROM of that axis). Unfortunately, that's an issue with either Epic's blender tools, Blender as software, or Unreal's FBX importer. Nothing I, as a template provider, can do about. As it is now, I couldn't track down when in the pipeline the error is introduced.

— Reply to this email directly, view it on GitHub https://github.com/gzmuszynski/UE-to-Rigify/issues/3#issuecomment-1564591651, or unsubscribe https://github.com/notifications/unsubscribe-auth/A7WH3DSF2F5GSLUNRSZ77VDXIDGHBANCNFSM6AAAAAAYNUVHX4 . You are receiving this because you authored the thread.Message ID: @.***>

gzmuszynski / UE-to-Rigify

Foot L/R and Ball L/R bones have odd rotation when imported into UE 5.1 #3