[Bf-committers] Animation regression, quaternion normalization

[Nathan Vegdahl]

> Hmm, I think we shouldn't change this without Joshua weighing in first,

Agreed.  He is the master of the animation system. :-)

> but... it might be good to have an operator for it in the meantime?

Good idea.  This would be easy to whip up as a python operator.  I can
whip one up after I'm done with the rigging DVD, or if anyone else
wants to whip it up it should be simple.  Just something that loops
over selections and normalizes quats on objects/bones set to
quaternion rotation.

--Nathan


On Tue, Feb 28, 2012 at 2:18 PM, Bassam Kurdali <bassam at urchn.org> wrote:
> Hmm, I think we shouldn't change this without Joshua weighing in first,
> in case something dangerous will happen, but... it might be good to have
> an operator for it in the meantime? so at least there's a way to
> normalize/fix (I realize that that conflicts horribly with Nathan's goal
> of not forcing animators to think about that stuff, something I agree
> with completely, but just as a stop-gap)
>
> On Tue, 2012-02-28 at 13:16 -0800, Nathan Vegdahl wrote:
>> Thanks Brecht!
>>
>> Yes, I think there are problems with this approach too, and I can see
>> why it would cause confusion.  But I think it's better to have this
>> for now until we figure out something better.
>>
>> One possibility would be to only have normalization happen when
>> inserting keys.  It's only a problem when things are animated, after
>> all.  That could also be confusing, though, since people will wonder
>> why the values change when they insert keyframes.
>>
>> Or perhaps we could have auto-normalization happen on frame changes?
>>
>> In any case, I think it's important that--however we set it
>> up--animators should not need to understand all of this to animate
>> with quaternions.
>>
>> --Nathan
>>
>>
>> On Tue, Feb 28, 2012 at 12:26 PM, Brecht Van Lommel
>> <brechtvanlommel at pandora.be> wrote:
>> > Hi,
>> >
>> > Ok, I found the commits that removed this auto-normalization. First it
>> > was changed for pose bones in r27200, and then for objects in r33523
>> > to make it consistent. For pose bones it was changed by Joshua with
>> > the comment "This was a constant source of confusion in the past, so
>> > let's see if we can do without it now :)".
>> >
>> > I can definitely see the interpolation issue when they are not
>> > normalized. So the question then is, what was this confusion?
>> >
>> > One issue perhaps is when you want to enter a particular value for the
>> > quaternion, if it keeps normalizing each time you enter a value, that
>> > would be a problem.
>> >
>> > Another issue with the implementation that I can see is that the
>> > normalization was done in object update, so not on editing only but
>> > also on any object animation evaluation. If you then animate only one
>> > of the quaternion components, the other values keep changing as you
>> > scrub through time and actually alter the animation. So perhaps that
>> > should be done differently, though it's not something you would do
>> > often I guess. Doing it immediately in RNA would also be problematic
>> > if you're setting the quaternion component by component in a script,
>> > the normalization does need to be delayed somehow.
>> >
>> > Further, probably Joshua knows, mailing this to him as well to get his opinion..
>> >
>> > Brecht.
>> >
>> > On Fri, Feb 24, 2012 at 9: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
>> >> _______________________________________________
>> >> 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
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers