I’ve been told that there is some sort of logic to the way Max handles rotations, but I don’t believe it. Often, especially but not exclusively when working with Maxscript, I will get extremely bizarre results, with things flipping around for no apparent reason. Take the following example:
I have an object which, on a particular keyframe, has a transform.rotationpart of:
(quat -0.193227 -0.486334 -0.56951 0.633878), or (eulerAngles 60.4844 23.3574 97.6194)
On the next keyframe, the object has a transform.rotationpart of:
(quat -0.158874 -0.390625 -0.624034 0.65784), or (eulerAngles 47.2297 18.4004 95.0796)
In practical terms, this is a total change in rotation of about 20 degrees. However, the actual result I am getting can be demonstrated by looking at the track view:
Can someone please explain to me exactly what it is that causes this to happen, and if there is any way to either prevent it or fix it after the fact?
How are you setting rotation? I can’t reproduce your results. I get a small curve no matter what I do.
I should probably have mentioned that the object in question is a bone in a rig. It’s usually bones that end up having these kinds of flipping issues.
All I really need is some way to “untwist” the track view curves between a keyframe and the keyframe following it.
PM: I looked the thread over, but didn’t really see anything there that applied to my problem?
Unfortunately if you are using Euler there is always the chance of flipping or gimbal lock, simply because the way the math works. TCB/Quaternions gets around this, but isn’t a “viewer” friendly way to work with keys in trackview.
How are you trying to control the rotations? What controller is being used? What coordinate space are you operating in? How much rotation are you typically dealing with?
Paul Neale has some great tutorials that cover why this is happening (not entirely on the maxscript side, but the general animation side as well) and may give you some pointers on the best way to approach it.
-Eric
i know about these problems of Euler Filter. I just want to know that is the case that can be solved with the Filter or it’s something different. There is a way how to do almost the same as the Euler Filter does but a little smarter.
I went back and looked at your results and the problem you have is how you are deriving your euler values.
quattoeuler (inverse (quat -0.193227 -0.486334 -0.56951 0.633878))
(eulerAngles 34.339 -56.7872 -102.84)
(inverse (quat -0.193227 -0.486334 -0.56951 0.633878)) as eulerangles
(eulerAngles 34.339 -56.7872 -102.84)
(quat -0.193227 -0.486334 -0.56951 0.633878) as eulerangles
(eulerAngles 60.4845 23.3573 97.6193)
quattoeuler (inverse (quat -0.158874 -0.390625 -0.624034 0.65784))
(eulerAngles 23.3751 -45.416 -96.8738)
(inverse (quat -0.158874 -0.390625 -0.624034 0.65784)) as eulerangles
(eulerAngles 23.3751 -45.416 -96.8738)
(quat -0.158874 -0.390625 -0.624034 0.65784) as eulerangles
(eulerAngles 47.2298 18.4002 95.0795)
If you used the method in the thread I linked to you will get proper rotation values. DO NOT!!! directly convert quats to euler you need to get the inverse of the quat (same as the rotation.controller.value). More on the topic can be found here.
-Eric
Ah, rotations, and to think they put a man on the moon using the same math and we have a hard time making a cartoon with it.
Hey DenisT, I’d like to know about the smarter Euler Filter How do you do it?
I’ve started a new thread because I thought it might help to explain the details of the situation that were causing the problems to occur:
Paul – you’ve been saying don’t scale bones forever, and I saw that section on your site, but really, if you first link the parent bone to a dummy, then scale the dummy, you dn’t get any problems at all, so I don’t know why you keep saying don’t scale bones…anyway, I think Malkalypse’s problems with rotation will go away if they are applied to a linked dummy object rather than the bone itself…
I tried matching a linked dummy to the rotations of the upper-arm bone in the chain’s IK enabled state, and it ends up having the same rotations as I get with the FK rotations for the bones.
I’m about 99.9% certain that the problem stems from the twisting track view curves (which, again, are present in the IK enabled state as well but “fixed” by the presence of the swivel target when the IK is turned on.)
Hmm…I had a quick look at yr file …I’m not sure but I think it has something to do with orientation of your bones and targets…make sure all the axes of helpers, targets and bones are oriented the same way.
Edit: post script – this may not be the forum for you on this issue. This is maxscript forum and the guys here tend to assume the problem is hi tech or heavy math, but in this case I think it’s quite simple. next time use the max forum.
Fresh Edit: read next page