[Bf-committers] Quaternion interpolation is bumpy/wrong

Nathan Vegdahl cessen at cessen.com
Thu Apr 26 03:19:57 CEST 2012


> But I think that this is not really the kind of
> interpolation an animator would want to have
> in this case.  As an animator I would prefer
> a direction interpolation and a separate "roll"
> interpolation.

Believe me, as an animator and rigger, I have thought about this
problem a lot.  But it's not as simple as you make it out to be.
Whenever you separate out axes of rotation like that, you introduce
singularities.  So you could, for example, use euler rotation with an
appropriate rotation order to accomplish what you want here, but then
it will interpolate strangely in other circumstances.

For example, in this file: http://www.pasteall.org/blend/13547
>From key-1 to key-2, and from key-2 to key-3, the interpolation
behaves as you expect.  But from key-3 to key-4 it behaves strangely.

Even if we hide the interpolation curves entirely and let Blender do
whatever strange things it wants to accomplish various interpolation
methods internally, it's not clear to me that there's an obvious way
to accomplish what you want in the general case, because "roll" is
actually ill-defined for fully general 3d rotations.  Besides which,
if we do that, then we deprive animators of a lot of control via
interpolation curves.

You might be able to accomplish something close to what you want via
some clever rigging, however, by having separate controls for the
pointing direction and the roll.  But you have to choose what
"pointing without rolling" means then, which involves making some
limiting assumptions.

In any case, there is nothing broken about how Blender is
interpolating your key frames.  I agree it's crappy for this use-case,
but I don't know of any existing methods that are less crappy.

--Nathan


On Wed, Apr 25, 2012 at 1:57 PM, Tobias Oelgarte
<tobias.oelgarte at googlemail.com> wrote:
> Yes, you're right. But I think that this is not really the kind of
> interpolation an animator would want to have in this case. As an
> animator I would prefer a direction interpolation and a separate "roll"
> interpolation. Ideally both rotations (as in your example files) would
> follow the same path on the rotation sphere, while only the roll behaves
> differently. Otherwise such movement will have this up/down curve, which
> isn't nice to look at.
>
> Greetings from
> Tobias Oelgarte
>
> Am 25.04.2012 22:21, schrieb Nathan Vegdahl:
>>> What i expected was a smooth motion, but
>>> instead it goes straight up (to 2nd key) and continues with a curve that
>>> _bends downward_ to key 3.  Given that it has to move trough the keys i
>>> would have at least expected a "linear" motion (shortest path) from key
>>> 2 to key 3.
>> The interpolation is not incorrect (insofar as interpolation can be
>> "incorrect").  If you were doing linear, shortest-path interpolation,
>> it _would_ be bending downward.  Your main misunderstanding is that
>> you are mistakenly thinking of the direction that the leg is pointing
>> as the only relevant aspect of rotation.  But that is not correct.
>> The twist of the leg is also part of the rotation, and you are
>> introducing a 90 degree twist with the second rotation.
>>
>> Take a look here:  http://www.pasteall.org/blend/13542
>> I've added "axis" bones to make it more obvious what's going on.  The
>> setup on the left is your animation, and the setup on the right has
>> been changed so that it's not twisting.
>>
>> Here's another file to take a look at:  http://www.pasteall.org/blend/13543
>> It's the same as the one I linked above, except with linear
>> interpolation (e.g. "shortest path").  It should be more visually
>> obvious in this why you're getting the "rotate down" effect.
>>
>> --Nathan
>>
>>
>> On Tue, Apr 24, 2012 at 3:12 AM, Tobias Oelgarte
>> <tobias.oelgarte at googlemail.com>  wrote:
>>> I don't know if this is a known issue. But i tried the following. I made
>>> a key for a leg (restpose),  bended it forward (xrot 90°, second key)
>>> and moved it to the side (zrot 90°, third key), and then added a fourth
>>> key (restposition again). What i expected was a smooth motion, but
>>> instead it goes straight up (to 2nd key) and continues with a curve that
>>> _bends downward_ to key 3. Given that it has to move trough the keys i
>>> would have at least expected a "linear" motion (shortest path) from key
>>> 2 to key 3.
>>>
>>> The reason for that is the interpolation (bezier curves) between the
>>> keys. It interpolates every component as a single key. But that isn't
>>> right for quaternion rotation. Instead it should interpolate between the
>>> quaternions (at the keys) itself using a slope function to define how
>>> the interpolation in between keyframes behaves.
>>>
>>> I uploaded an example to pasteall.org to illustrate the issue:
>>> http://www.pasteall.org/blend/13505
>>>
>>> The left armature (named "wrong") shows what i mean with wrong
>>> interpolation and the right armature shows how it should look like
>>> (named "nearly right", because it is impossible to get it right at the
>>> moment).
>>>
>>> Maybe someone has the time to look at the example and to figure out a
>>> way how it could be correctly implemented. My attempt would be to remove
>>> the possibility to edit f-curves for quaternions (who does that anyway?)
>>> and to use another interpolation scheme for this kind of rotations.
>>>
>>> Greetings from
>>> Tobias Oelgarte
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list