[Bf-committers] Animation regression, quaternion normalization

Nathan Vegdahl cessen at cessen.com
Fri Feb 24 21:55:38 CET 2012


Here's a file I put together a while ago to help explain the issue and
why it matters:
http://storage.cessen.com/perm/2012/blender/quat_interpolation.blend

If you open up the file, you'll see two monkey heads, each with an
illustration above it.  If you play the animation, you'll see that the
monkey head on the left has a strong ease-in-ease-out in its rotation.
 The monkey head on the right, however, has a very linear-speed
motion.

However, both of them are using linear interpolation!  The only
difference is that the monkey on the right has additional normalized
key frames between the beginning and end of the animation.  The
illustrations above help give an intuition as to why this happens.

When animators are in the blocking stage, sometimes they will have
very large rotations between key frames, and only later in the process
will they come back and fill in the breakdown keys.  If those
breakdowns aren't normalized, then the animator will be fighting with
the "ease-in-ease-out" of the quaternion interpolation to get the
actual rotation speeds they want.

The file I've linked to is exaggerated, of course.  Few people will
key 270 degrees of rotation with just two keys, even in blocking.  But
subtler versions of the same effect can still happen.

--Nathan


On Fri, Feb 24, 2012 at 12:37 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
> Hi Brecht,
> You are right that it appears there are a lot of releases with this
> regression!  I'm not sure how I didn't notice before.  Guess I wasn't
> animating anything with large rotations.
>
> It appears the regression was introduced in version 2.56.  Versions
> 2.55 and earlier behave as desired.
>
> 2.4x and earlier _do_ auto-normalize (I just tested).  In the 2.4x
> series quats are displayed as eulers in the n-panel, so you have to
> set keyframes and look at the values of the keys in the Ipo editor to
> see the actual quat values.  Try, for example, keying a bone unrotated
> on frame 1, then rotated 180 degrees on frame 21.  On frame eleven
> it's clear that the values given by the Ipo curves are not normalized.
>  However, if you move to frame 11 and set a key, the inserted keys are
> normalized.
>
> This is a highly desirable behavior, because it keeps quaternion
> values from drifting and causing rotation speed issues with
> interpolation.
>
> Perhaps we could just normalize quaternion values upon inserting
> keyframes?  That is the primary use-case here.
>
> --Nathan
>
>
> On Fri, Feb 24, 2012 at 7:51 AM, Brecht Van Lommel
> <brechtvanlommel at pandora.be> wrote:
>> Hi Nathan,
>>
>> I tried manually typing in non-normalized values in the N key
>> transform panel in the 3d view, and rotating objects/bones after that
>> with transform, but could not see it auto-normalize the values in any
>> version I tested (2.49, 2.57, 2.60, 2.62).
>>
>> Probably I'm misunderstanding something, but I can't find any traces
>> of this feature.
>>
>> Brecht.
>>
>> On Thu, Feb 23, 2012 at 11:03 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>> Hi guys, I wrote to the list about this before but received no response.
>>>
>>> I don't know when this was changed, but quaternion rotations for
>>> objects and bones in Blender are no longer auto-normalized for the
>>> user.  I am frustrated that a release (2.62) made it out the door with
>>> this being the case, as it substantially harms the practicality of
>>> animating with quaternions.  It is not "incorrect" behavior per se, so
>>> I am hesitant to file a bug report.  But it is something that needs to
>>> be changed.
>>>
>>> I think we either need to revert behavior back to how it was before
>>> (quaternions being auto-normalized in the transform panel), or find
>>> another solution.  But as things are right now, quaternions are
>>> impractical to animate with in many circumstances (especially doing
>>> blocking on characters involving large rotations).  I will be happy to
>>> provide a technical explanation of why that is the case, but at the
>>> moment I am swamped trying to finish my rigging DVD.
>>>
>>> I just want to make sure this doesn't slip into the next release as
>>> well!  It is a serious regression.
>>>
>>> --Nathan
>>> _______________________________________________
>>> 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