Any obvious reasons/workarounds for this strange quaternion interpolation?

Zablorg

I'm trying to animate a leg swing with quaternion bone FK. There are two frames in particular (denoted 6 and 12 in the bottom of the gif below) where the resulting motion of the left (front) leg is not as desired: the limb chain overshoots in a small arc.



The culprit seems to be the contribution of the thigh. All the f-curves all seem fine- the xyz quaternion values aren't shooting off to greater values than anticipated, or anything. I haven't included the previous frames in the gif, but rest assured they're not in a position that would make this arc intuitive, obviously.

 And adding keyframes doesn't exactly seem to work, either. It seems that this overshoot is just a property of those particular quaternion values, for whatever reason.

I'm using Blender, if that's of any help, but this doesn't seem application-specific so much as just a property of rotation math. Is there a name for this behavior, or some common workarounds for it?

Note that the use of IK is not a valid answer in my particular case.

Eric Chadwick

The excellent Paul Neale might be able to help your understanding of why this occurs.
https://paulneale.com/quaternions/

RN

Zablorg said:

the xyz quaternion values aren't shooting off to greater values than anticipated

Quaternion rotations in Blender are supposed to fix the "gimbal lock" problem inherent to Euler rotations, but Quaternions have XYZW curves, and you said your curves are XYZ (no W).
Are you sure you're using Quats?

Also, from your GIF, you're using Rigify and (here on 2.79 at least) that rig uses ZXY Euler mode on the thigh to let you control the leg roll using its local Y axis (something more difficult to do if it were in Quaternion mode). So it's susceptible to gimbal lock.

RN

(All of that, if it's not just bad keyframing on your part. Rotations from different bones do accumulate and produce that kind of movement, nothing to do with gimbal lock).

You can try the motion paths tool to see if there's any bones causing this: https://docs.blender.org/manual/en/latest/animation/motion_paths.html

Zablorg

Hi everyone, thanks for your input. To address a couple of things:

1. Motion pathing has confirmed that the thigh, specifically, is moving in that undesired arc.
   
   
2. The thigh is using quaternion mode- I just neglected to list the W component in the post.

Any possible workarounds for this? I don't really know where I'd begin.

Zablorg

Okay, looked into this a bit more. The thigh bone, in isolation, is actually interpolating in a pretty ordinary fashion- it's more that the sway of the hips are then disrupting the arc to buck in a way I don't want.

Haven't solved this yet as such, but it's a much clearer problem definition. I think more key frames are going to help now, as I have a better sense of where to put them.

RN

The solution is to use IK instead of FK.
Rigify has switches so you can alternate between the two modes on adjacent frames.

Zablorg

RN said:

The solution is to use IK instead of FK.
Rigify has switches so you can alternate between the two modes on adjacent frames.

Aware of this, and indeed IK is how I was getting the FK positions to keyframe. The point of all this was to try to get this to FK-only, but I've solved it now in any case.

I see that my post said that "use of FK" wasn't a valid answer, but it should have said "IK".

RN

I guess this is more of a question for the animation forum, but why is FK still a thing? There's not one movement you can't do with an IK limb, whereas using FK makes some movements (like the one you're talking about, keeping a bone steady while its parent moves) very annoying to do.

Zablorg

RN said:

I guess this is more of a question for the animation forum, but why is FK still a thing? There's not one movement you can't do with an IK limb, whereas using FK makes some movements (like the one you're talking about, keeping a bone steady while its parent moves) very annoying to do.

In my case I was interested in defining the motion in FK and then tweaking things around a bit on a limb-segment basis, like offsetting the calf by like a frame or something.

I suspect FK might be cheaper to run in-engine, but I'm not really sure if that's true or by how much. Probably easier to set up in-engine, too.

RN

I'm sure there are FK uses I'm not thinking of. I'm so attached to IK that I'd rather find a way to use that instead (like a Child Of constraint to let the IK target be parented to the calf on some frames, for instance).

But about engine support, you bake the transform of bones into FK keyframes (you sample the bone transform on each frame and store it as an FK keyframe). This way you can use not only IK but fancy constraints / drivers while authoring the animation, and have the same visuals in the game engine that might not support them.

That is, unless you're doing something like Starcraft 2 with those Colossus spider things whose legs adapt to terrain, in that case it's real-time IK solving on each leg.

Alex_J

In my tiny experience doing animations, FK is quicker to work with for certain limb movements as it works with complete predictability. Sometimes IK doesn't interpolate the way you want. Also when you move part of an IK system, everything attached comes with it. In order to just tweak one part, you gotta locked off all the others. That's a big pain. With FK it's easier to work on things in isolation.