1
General Anim8or Forum / Re: Help with correcting orientation problems
« on: May 01, 2009, 03:25:09 pm »
I won't split hairs then. Thanks again for all the help.
Anim8or Community
- April 04, 2025, 06:43:48 am
- Welcome, Guest
News:
Ian Ross has just released a book on Anim8or. It's perect for a beginner and a good reference for experienced users. It contains detailed chapters on every aspect, with many examples. Get your own copy here: "Anim8or Tutorial Book"
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
General Anim8or Forum / Re: Help with correcting orientation problems
« on: May 01, 2009, 01:30:29 pm »
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.
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.
3
General Anim8or Forum / Re: Help with correcting orientation problems
« on: May 01, 2009, 09:28:13 am »
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!
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!
4
General Anim8or Forum / Re: Help with correcting orientation problems
« on: May 01, 2009, 01:32:23 am »
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.
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.
5
General Anim8or Forum / Help with correcting orientation problems
« on: April 30, 2009, 02:49:44 pm »
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.
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.
6
Anim8or v0.98 Discussion Forum / Re: Bug/Glitch - Orientation?
« on: April 30, 2009, 10:07:39 am »
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.
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.
7
Anim8or v0.98 Discussion Forum / Bug/Glitch - Orientation?
« on: April 29, 2009, 02:33:02 pm »
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!
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!
Pages: [1]