Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dtrbc]

Hello all,

This is based on a question I initially posted in the .97d preview forum, thinking it was a bug, but have now learned it is just an intrinsic problem in 3D animation.

I've been using anim8or for a few years, since mid 2006, and have always had an issue when rotating and object that, at some points in its rotation the orientation values will shift off a fraction of a degree. Thanks to user RudySchnieder, I now know this is related to the phenomenon of gimbal lock. Now I'm asking for help on what I can do to get around it.

I often have to work with very long scenes, and often have a lot of rotation going on--my job requires me to animate planets with accurate axial tilts, and this seems to be where the worst problems occur. I used to animate with keyframes, but have lately been using controller scripts. With keyframes one can sort of correct for the problem, but I have found it can be a huge timesink going through and trying to correct every little spot where it goes off--not to mention it can consume a lot of time to make a planet spin around and around and around a dozen times with keyframes, so I started using controller scripts.

I am wondering what I can do to correct for the problem of the object wobbling a little bit at some points when using a controller script. Here's an example script I was using in a recent project, this script controlled my camera's orientation:

float $speed;
$speed = -2;
$orientation = RPYtoQuaternion(-1., 0., ($speed*time));

It encounters problems near frame 0 and every 5400 frames thereafter (the sequence I'm making is 10800 frames long, 30fps).

Would it be possible to add or modify anything to correct for this problem?

Thank you so much for any help and, if I may add, a big thanks to Steve for making anim8or. It's an incredible program.

[NickE]

I would suggest using quaternions directly rather than converting the Roll-Pitch-Yaw to a quaternion.  See the wikipedia page:

http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation

and this page:

http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/
Be sure to look at the sidebar "Quaternion Physical Interpretation".

[dtrbc]

Thank you for the reply.

I see that quaternions, by nature, should avoid the problems I'm having, unfortunately, even after reading both of those pages over and over, I still am unclear of exactly how to work quaternions (I've even gone to look for my old scientific calculator from back in school). I seem to be able to make one axis work more or less correctly, but anything beyond that and I'm just getting confused--for example, how might I translate my above script into a quaternion?

And, if I'm not mistaken, is quaternion using radians?

Is, perhaps, my problem that quaternion only expresses rotation, and not an orientation position--if I enter any value for any quaternion, it does not create a static orientation, but a rotation-inducing variable? If that's the case, how would I create a static position (such as the -1 degree in my script above)?

Thanks so much for any help.

[ENSONIQ5]

Hi dtrbc

The following script defines a rotation using quaternions, without a RPY conversion (I did not write this):

float $speed;
$speed=-.5;
$orientation = (sin($speed*time),0,0,cos($speed*time));

Adjusting the $speed variable alters the speed (obviously), and the rotation axis can be changed by changing which of the first 3 quaternion values are affected by the "sin" function.  For example, the script below rotates in a different axis to the one above:

float $speed;
$speed=-.5;
$orientation = (0,sin($speed*time),0,cos($speed*time));

I have to admit that I struggle a bit with the quaternion concept, but this script does the job nicely and that's all I really care about!!

EDIT:  This basic script can be modified to get different effects.  For example, I wrote the script below for a Solar system model, which I wanted to run at a certain speed for a given time, and subsequently accelerate for the remainder of the animation:

float $speed;
float $trigger;
float $rate;
$speed=0.004155;
$trigger = max(time, 29);
$rate=($trigger*3.5)-100.5;
$orientation = (0,sin(($speed*$rate*$rate*time)+2.5),0,cos(($speed*$rate*$rate*time)+2.5));

The $speed variable sets the initial speed of rotation (in this case it's Mercury's orbit I think); the $trigger variable is either the time, or a preset figure, whichever is higher, which sets the trigger time for acceleration; and the values in the $rate calculation were chosen so that $rate would equal 1 for the initial period, and increase in a linear fashion thereafter.  Since $rate is squared in the $orientation calculations the result is an acceleration.  The values of "2.5" in the $orientation calculation set the starting rotation of the object being affected by this script.

ANOTHER EDIT:  Wouldn't the gimbal lock effect be negated if RPY adjustments were always relative to the object itself, rather than to the "universe"?  In one of the links above was an aeroplane example to explain gimble lock, where if the plane were to climb 90 degrees to horizontal then roll and yaw would be the same motion.  However, a real aeroplane experiences no such "gimbal lock", because it's frame of reference moves with it.  Pitch, roll and yaw are always relative to the plane itself, not the Earth.  Hmm, my understanding of the guts of 3D modelling is limited to say the least, so perhaps the ability to choose the reference frame within which an object rotates is not feasible.

[Kubajzz]

I recently spent some time trying to find out how quaternions work and although I don't understand the whole theory, I found several important and easy-to-understand facts (somebody correct me if I'm wrong):

• A quaternion contains information about the rotation axis (represented by the first 3 vector components in Anim8or) and the angle of rotation (the last number).
• Every possible orientation of an object can be achieved by doing one rotation around a specific axis - that's why the information stored in a quaternion (an axis and an angle) is enough to describe every possible position.
• Because a quaternion can be used to describe every possible position, it can also be used to represent any kind of rotation - you can animate the angle of rotation, the axis or both.
• One important thing is: if you want a quaternion to work correctly, it's values must be normalized: (x * x) + (y * y) + (z * z) + (w * w) = 1

You can get a quaternion from axis and angle using the following formula:

qx = ax * sin(angle/2)
qy = ay * sin(angle/2)
qz = az * sin(angle/2)
qw = cos(angle/2)

- "qx", "qy", "qz" and "qw" are components of the quaternion
- (ax, ay, az) is a normalized axis vector
- "angle" is (surprisingly) angle.

If the axis vector is normalized, it's not that difficult to find out that the whole quaternion will be normalized as well.

Let's look at the script ENSONIQ5 posted to see how the theory works:

Code: [Select]

float $speed;
$speed=-.5;
$orientation = (sin($speed*time),0,0,cos($speed*time));
- in this case "$speed*time" is the angle of rotation and the axis is (1, 0, 0) (note that it is a normalized vector). Therefore this script will make your object rotate around the "x" axis. Simple, isn't it? 

Is, perhaps, my problem that quaternion only expresses rotation, and not an orientation position--if I enter any value for any quaternion, it does not create a static orientation, but a rotation-inducing variable? If that's the case, how would I create a static position (such as the -1 degree in my script above)?

Like I said before, it is possible to represent any arbitrary rotation and orientation using a quaternion... However the fact that it is possible does not mean it is always easy. If I understand it right, you first need to tilt your object a little bit and then let it rotate around one if it's "original" axes. If you wanted to describe this kind of rotation using a single quaternion, I think you would have to animate both the angle and the axis and that might be really difficult.

The easiest solution is to add one more "dummy" element to your scene:

• Click "Build>Add Target" to add new invisible element and make this element parent of your animated object
• Whenever you want to move your planet (or whatever it is), move the target instead
• Tilt the target a little bit (I guess -1 degree around the X axis in your case)
• Now you can make your planet rotate using a simple quaternion formula like the one Ensoniq5 posted

I hope this helped a little bit Good luck!

[ENSONIQ5]

Nice Kubajzz!  Even after a bottle and a half of Shiraz that makes more sense than the Wiki article on the subject!

[dtrbc]

Thank you Kubajazz, that makes a lot of sense!

In my hours up way-too-late last night obsessively trying to understand this I did find that rotation forumla posted on these forums and learned its operation (I notice if you substitute multiples or divisions of PI for the speed you can get values that occupy even and full second--so that solves one problems I would seem to have with it). I also stumbled upon using tan($speed*time) with a qw of 1 would also generate the desired rotations (except encounters the problemed spots where the function approaches infinity).

Your explanation simplifies it quite a bit, and your solution with the target object for a parent is exactly what I need--it's quite embarassing that the problem had such a simple solution! I also see the need for normalizing, and understand why its so hard to get something working just by plugging in numbers, because it will not be able to remain a normalized equation--hence, I suppose, the calculation matricies on all the explanation sites.

I may not completely understand all that is going on here, but your solution should allow me to do everything I need to do for the near, forseeable future, so thank you so much!

Also ENSONIQ5, I think you might be right about such a frame of reference change avoiding gimbal lock. I learned how to do 3D animation in a piece of astronomy-specific software (a very old piece of software from the early 90s), in which everything was, more or less, relative to itself. Objects could be commanded with both RPY and Right Ascension, Declination and Heading, but the programmers, evidently aware of the ability to encounter this problem, constructed it so nothing would encounter gimbal lock. I suspect this may have been done by having no world that objects were really compared to, just independently for the objects themselves. At least, that's my guess from what I know of it. The very way they arrived at this solution may even have something to do with thining of it like being in a plane, since I know they also developed flight simulator software for the government back in the day.

Again, thank you both so much!

[fik]

This site explains Quaternion's and a whole lot of other related stuff very well.
http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/index.htm
 Hope you might find this usefull.

[dtrbc]

Thanks everyone, I've got them all running smoothly now, and with parent relationships seem to have my other rotation needs taken care of.

However, I think I've seen something else that appears to be a bug--or else maybe I'm not inputting numbers right.

I noticed with some positional controls on my camera that when calculating sin and cosine, at the values near zero anim8or calculates to about 4 decimal places (or at least, that's what is shown in the display window), but near 1, anim8or rounds up to 1, and when it does start counting back down, seems to only calculate to two decimal places. If I'm doing very slow motion, I've noticed this can create something that visually resembles gimbal lock. Is anim8or rounding things too much on its trigonometric functions, can it not handle numbers with many digits on both sides of the decimal place, or am I entering something wrong?

For reference, the script:

float $speed;
$speed = PI/90;
$position = (180*sin($speed*time), 0., 180*cos($speed*time));

Right at the start the cosine value is 1 (expressed value is 180 with the amplitude increase), and while the sine value starts to slowly count up, the cosine value stays frozen at 180 for several frames. This causes it to be in slightly the wrong position (and for the camera to face slightly off center) for a few frames as the sine value increases without the cosine value decreasing, then rebound once it starts to count down from 180.

[Kubajzz]

I don't think it's a bug... I tried out your script and I think it does exactly what it should do.

Here is a little comparison of the values Anim8or generates and real values it should use (assuming the frame rate is 30 fps):

• frame 0: value 180; should be 180
• frame 1: value 180; should be 179,999878...
• frame 2: value 180; should be 179,999512...
• frame 3: value 180; should be 179,998903...
• frame 4: value 180; should be 179,998050...
• frame 5: value 180; should be 179,996953...
• frame 6: value 179,99; should be 179,995613...
• ...

As you surely know, there is a little rounding error that cannot be avoided because computers simply cannot handle exact floating point values. Anim8or seems to round the values in the window so there are always only 5 digits, but I think that's only because the input window is so small and the actual value Anim8or works with is much more precise.
Well, 2 decimal places are usually more then enough anyway...

[dtrbc]

I won't split hairs then. Thanks again for all the help.