Snap IK -> FK when creating control rig

[alexander94dmitriev]

When working with control rig I usually work with limbs having IK turned on. It seems that with UeToRigify there's no option to do it during conversion and we need to do it manually.

Is there a way to make baking animation from source to control rig with IK to FK being enabled?

I also am curious about the optimization of this operation as it seems to take too long (much much longer than it takes to generate UE5's whole Control Rig). But it seems to be a Rigify issue.

[james-baber]

Hey, @alexander94dmitriev you are right that youll have to switch IKs on in the Rigify settings after changing to control mode. In general, there are some improvements that could be made to preserving the state of the rigify rig in control mode.(including remmbering which IK/FK and other rigify settings were set, etc.)

The speed of the operation will depend on the complexity of your rigify rig. The baking is using blender's bake visual transforms which can also take long depending on keyframe range and number of bones. Otherwise it is the rigify building step that takes the longest, and that is all based on the rigify addon

[alexander94dmitriev]

@james-baber what could be a good resource to reference the issues with baking keyframes? I have noticed multiple times that baking from IK chains (primarily legs) can provide unpredictable results (e.g. sliding foot or random stretching)

[james-baber]

Yea I guess it depends on when your noticing the issues. Is this noticeable in Blender, or not until the asset is in unreal?

On the unreal import side, I would highly reccomend keeping this on

This should help with accuracy alot since transforms are calculated in local space which can help with floating point issues.

Other then that you might have to dig in a bit when your experiencing these specific cases. Depending on your Python experience https://github.com/EpicGames/BlenderTools/blob/6ee65be54c3e12d696cde791534fc02a7d2d0d50/tests/utils/base_test_case.py#L545

This will help when comparing world transforms of bones between unreal and blender and doing the coordinate system conversions. However in my experience with this method has been that the floating point precision of a world transform drastically drops off after 15ish cm from Blender world origin to is it is hard to a get an exact match rounded to 2 decimals. So this could help to a certain degree when trouble shooting differences in bone transforms if your character animation is pretty close to world origin.

So might help find the issue, but not fix it. I have found the best results with what is default in send2ue setting and blender. But you could play with the IK solver if the issue is in blender(however I have found standard to work best in the cases I have tried).

Otherwise maybe check how sparse your keyframes are in blender and unreal and try to get more keyframe samples in the animation.

Hope that helps

[alexander94dmitriev]

Thank you!

I definitely have noticed that importing Preserve Local Transform is crucial when importing animation to UE5.

To specificy, my current workflow is recording VR mocap animation in UE, exporting to blender, adding the animation to source skeleton and rebuilding the control rig.

I have noticed that quite a few times converting BACK from control rig to source skeleton is when results are getting inconsistent. Specifically it seems to be around the limbs. You can see over here the control rig animation and then bakend animation as a result here. With IK controls mostly being still the feet are sliding noticibly. What is also concerning is for some reason baking operation performs scaling changes there did not take place in the control rig animation. But I think these are coming from twist bones.

https://user-images.githubusercontent.com/22586542/195423807-d2675645-cedc-4d5c-84b6-d63d27a00534.mp4

[james-baber]

Hmm yea that is interesting. The baking logic isn't in the addon, but it just calls the bpy.ops.nla.bake() operator. The bake is one sample per frame, and the input in an int so to get subframe samples youd need to bake another way.

However, looking at the feet drifting, that doesn't look like it is happening intraframe, but across several frames, so Im not sure that more samples would fix this.

You might try running this in control mode with all your bones selected in pose mode.

import bpy
bpy.ops.nla.bake(
        frame_start=1,
        frame_end=20,
        step=1,
        only_selected=True,
        visual_keying=True,
        use_current_action=True,
        bake_types={'POSE'}
    )

Then staying in control mode delete the constraints, emptys, and rigify rig and see if the bake is any better.

The reason is that, UE to Rigify only selects source bones before the bake that have a link to some FK bone in the node tree, otherwise the bone is not selected. So that could be what is happening here. Maybe the bones you need baked are not being baked(which might be able to be fixed with your template).

Also might be able to just set this to true in your addon code then restart blender and register the addon https://github.com/EpicGames/BlenderTools/blob/d8581500a65d8510aaac56fcd933a110bc4e6171/ue2rigify/core/scene.py#L1156

and see if that fixes this issue.

[alexander94dmitriev]

@james-baber thank you very much for a great option, this might work for my needs! However, I did notice that when baking with these oprations to the original source the spine bones scale is distorted as well. But twist bones are static. I wasn't sure where does baker picks scaling parameters from for spine bones.

[james-baber]

I believe the visual bake should include loc rot scale. If twist vs def are getting baked/not baked that could be a template issue, since it only bakes bones that have links currently. If allowing all bones to bake fixes this issue, maybe we could add a option to bake all bones regardless of their relationship?

[james-baber]

This should be fixed in the latest release. With the "Bake all bones" option. Re-open if you are still experiencing issues