Poke poke, to Aligorith. Can you please weigh in on this? --Nathan
On Tue, Feb 28, 2012 at 11:04 PM, Nathan Vegdahl <ces...@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 <bas...@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 >>> <brechtvanlom...@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 <ces...@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 >>> >> <brechtvanlom...@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 <ces...@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@blender.org >>> >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> _______________________________________________ >>> >>> Bf-committers mailing list >>> >>> Bf-committers@blender.org >>> >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >>> >> Bf-committers mailing list >>> >> Bf-committers@blender.org >>> >> http://lists.blender.org/mailman/listinfo/bf-committers >>> > _______________________________________________ >>> > Bf-committers mailing list >>> > Bf-committers@blender.org >>> > http://lists.blender.org/mailman/listinfo/bf-committers >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
