FBIK behaviour changed after "optimization" changelist 44325624

Development Character & Animation
, ,
1

Hello,

in my previous question [Let Full Body IK account for changes in bone lengths in [Content removed] we talked about using full body IK on bones, that have their lengths modified by an animation, thanks to Kiaran Ritchie’s help we resolved it. Since then I have started using latest green builds and I have encountered another issue, which I pinpointed to one change in CL 44325624 / https://github.com/EpicGames/UnrealEngine/commit/5c29b07fb809edf7e9689c986d3c1afaf3054693\#diff\-05e946d1f0ae4fa1d1fec76fd282bfc6e398df5a03b15d4642b10ebdf9e40376

Specifically one small change in PBIKConstaint.cpp lines 43,44 old / 55,56 new: the old code used the ‘Correction’ vector for ApplyPushToRotateBody of both A and B matrices, only with opposite direction. The new code uses the CorrectA and CorrectB vectors instead. If I understand right, those are effectively the Correction vector weighted by the mass of body A and B.

Video in the attachment shows differences between the new and old version. The bone that is at the beginning inside the green and red spheres should remain in the green sphere (“DesiredHitTarget”) thanks to how the IK is setup (more details in the previous question). In the beginning of the video I show that it does not follow the target. Then I revert to the old version (then there’s a long wait for live recompile in the middle, sorry) and that works much better, the bone stays with the target (until some extreme point where it’s limited by the constraints in my IK setup).

Maybe the problem is that my bone has zero length in the default skeleton, but the animation prolongs it, hence changing the mass? I tried doing the same experiment with a bone that does not have it’s length changed by the animation and saw no difference between the old and new code. Anyway, the main question is, is the “new” way of handling ApplyPushToRotateBody really correct? I don’t have nowhere near enough understanding of what the code actually does to tell. But the changelist’s description says its just optimizations, so I would expect no change in behaviour, but it seems there is one…

2

Steps to Reproduce
Same as in previously reported issue [Let Full Body IK account for changes in bone lengths in [Content removed] the data I uploaded there can be used for this issue as well:

  1. Setup Control rig with Full Body IK node with one bone as an effector
  2. Add Control for the effector bone
  3. Take some animation and change the translation of the chosen bone significantly
  4. Use the animation for preview of the control rig
  5. Set the translation target for the effector bone to match the control
  6. Move the control in the preview - observe the effector not actually match the Controls position despite it being set as the target
3

Hi Tomas,

Appreciate your patience while we dealt with some technical hiccups with my access to the support ticketing system.

Thank you for putting together the video, that was very informative. The result of the new behavior is the “correct” behavior because it takes into consideration the bone length when rotating the bones to resolve a joint constraints. This way longer bones have more inherent resistance to motion than shorter bones.

This can however increase the amount of iterations required to achieve convergence between the end effector bone and the goal location.

The additional inertia that this causes can be compensated for by lowering the overall Mass Multiplier. Please try lowering the Mass Multiplier to bring the total resistance to motion down. Bringing this too low can cause divergence (exploding solves). But it should generally be tuned as low as possible while still remaining stable.

This alone should resolve your issue. I do not believe it has anything to do with your bone being animated. The effective mass of the bone is calculated each frame (in UpdateFromInputs()) now to account for animated translations.

Please let me know if the Mass Multiplier tuning resolves the convergence issue for you.

Kind regards,

Kiaran

4

Glad to hear Tomas. We are stabilizing the FBIK plugin and should move it to production ready soon so you can be sure we won’t have behavioral changes going forward.

Cheers,

Kiaran

5

Hello Kiaran,

thanks for confirming it’s right this way. You were right about the mass multiplier, tweaking it resolves my issues even when using the “new” code.

Best Regards,

Tomas