Print

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

[dtrbc]

Hello, I hope this is the right part of the forum to post this in.

I've been using anim8or for a few years, since version .9, and I've always encountered this bug--including, most recently, in .97d.

When I make an object rotate, that is, change its orientation continually (either with a keyframe for each 90 or 120 degrees of the rotation, or with a controller script), at some point during the orbit the object will shift slightly off the prescribed course. This usually seems to happen near 90-degree intervals--sometimes at, say, 0 90 0 or 0 0 0 or 0 0 90 or 90 0 0, depending on the original orientation of the object--it's different depending on the original orientation, but pretty much seems to always happen at least once per rotation, always in the same spot. Over the course of about three or four frames the values will shift off by a small amount (a fraction of a degree), but enough to make an odd, noticeable wobble in the final render. When I used to do everything by keyframes I could sometimes force it to work right, but now that I use scripts, there's little I can do.

Has this been encountered before? Can anything be done about it?

Thank you so much! This problem aside, Anim8or is an amazing program and can do some amazing things!

[RudySchneider]

Anim8or, and other programs, have certain rules regarding rotation.  Sometimes you need to put some interim steps between your 90-degree way points, because from a strictly mathematical point of view, it may calculate that there's a quicker way to get from point X to point Y, which involves rotating about another axis.  So, sometimes you need to force the key frames to go the way you want.

Another phenomena is gimbal lock, and it's the bane of not only modelers, but any mechanism where the axes of a multi-axis system can line up with another axis.  It has to do with how you reference an object's local axes with those of the outside (or world) environment.

From a static, local point of view, the X-, Y-, and Z- axes are always orthogonal (separated by 90 degrees) to each other.  If you rotate an object along its X-axis only, once it rotates 90 degrees, its Y-axis corresponds with the Z-axis of the outside (world) coordinates.

A classic problem in the real world is a telescope, or radar, which must "track" an object that goes directly overhead.  Put yourself in the role of either of these devices.  Let's assume you're tracking the path of the space shuttle.  It first comes into view on tyhe horizon, and your body is facing a certain direction so that you can see it.  As rises higher in the sky, your body continues to face the same direction, but your head rotates upward.  Once the shuttle passes directly overhead, your body may still be facing the original direction, but now your head is looking straight up.  In order to maintain your vision of the shuttle as it continues on its path to the opposite horizon, you must either rotate your body around 180 degrees, or continue to tilt your head back (uncomfortably). 

There are ways around this situation (at least for real tracking mechanisms), such as offsetting the axes, but they generally rely on some advance knowledge of what may happen, so that they can avoid gimbal lock.  Similar steps can be taken in the modeling and animation world to avoid the situation, but I don't know of anything that can eliminate it altogether.  The rule of thumb is to plan ahead.

[dtrbc]

Ah, thank you, that makes perfect sense, as does being able to work around it with keyframes.

However, when rendering a very long sequence, keyframes are not the most convenient--how might one be able to deal with it using controller scripts, if at all? For example, in a scene I'm currently working on, my camera is affected, and I was running the following script on it:

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?

Should I re-post this in the general forum, where it might be more appropriate?

Thanks.

[RudySchneider]

dtrbc ---

Hmmm, I need to mull that one over.  But, yes, you're more likely to get contributing ideas in the General Forum.  By the way, it's not that you necessarily need a lot of keyframes, just so you add keyframes near crucial points.

For instance, many people have difficulty stopping motion, because Anim8or normally applies spline curves to keyed motion.  A simple fix for this is to simply add one more duplicate keyframe immediately before or immediately after the motion profile.  That way, you can get the smooth, "ease-out" and "ease-in" motion between the end points, but the motion will stop, rather than possibly drifting after the last keyframe.