[Bf-committers] Animation regression, quaternion normalization

Wed Mar 7 20:39:04 CET 2012

Poke poke, to Aligorith.  Can you please weigh in on this?

--Nathan

On Tue, Feb 28, 2012 at 11:04 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> 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