Attached Link: Download the Axis Test Prop Here

Greetings all, While I don't want to start one of those long debates involving endless speculation *grin* - I do want to bring up an old, OLD subject that has never been addressed to my satisfaction. That is about the object ROTATION transform dials and the way they behave in Poser.

I have just concluded a LENGTHY investigation, and have come to several conclusions upon which I invite you all to test and comment, but PLEASE don't theorize or speculate - that just confuses everybody! To help you perform some OBJECTIVE testing on your own, I have made a special prop which you can download at the link above.

Included in the zip package is a pz3 file which has the prop and cameras all set for your testing. The prop is also available separately in your props folder. The Readme file includes detailed step-by-step procedures to demonstrate the behavior I have observed. I won't explain it all here, but it is included in the package (which is only a 53Kb download with everything included).

To keep this post short, below are the CONCLUSIONS that my testing has revealed abour object rotation and object axes within Poser:

CONCLUSIONS:

1. EACH ROTATIONAL AXIS WITHIN POSER BEHAVES DIFFERENTLY as if the code for each were written to different standards. Whatever is going on here, it is NOT consistently applied to each of the three axes, and is the source of much confusion in the Poser community.

2. The Y-Rotate is CONSISTENT - It ALWAYS rotates the object around the object's LOCAL Y axis, regardless of the setting of the other two dials.

3. The Z-Rotate is CONSISTENT - it ALWAYS rotates the object around an axis which is parallel to the GLOBAL Z axis, but runs through the center of the object. This is true regardless of the setting of the other two dials.

4. The X-Rotate is INCONSISTENT - it appears to be an imaginary axis which is a HYBRID derived from whatever the CURRENT LOCAL Y and LOCAL Z settings are - perhaps it is a mathematical vector between them, but it is difficult to observe with that kind of precision. If the yRotate dial is ZERO and the zRotate is set to some value, THEN the X-Rotation appears to be parallel to GLOBAL X axis. On the other hand if yRotate is set to some value and the zRotate is ZERO, then the X-Rotation appears to be about the LOCAL X axis. IF BOTH Y and Z rotations are set to some non-zero value, then the X-Rotation seems to be around a HYBRID axis somehow related to whatever the CURRENT settings are for the yRotate and zRotate dials are.

As I have said above, I cannot explain WHY the makers of Poser have chosen to do things in this manner, but from my perspective, it seems to make NO SENSE. It is not even consistent within itself, and in several years of reading the Poser forums, I have never seen a satisfactory explaination of this phenomenon. If anybody knows the REASON for this behavior and can tell me how it is appropriate, I would appreciate it. Otherwise, I think it is a serious FLAW in Poser and should be FIXED.

I invite all who are interested, to download the prop and perform the same tests. Perhaps the reason that it has been so difficult to explain the rotational problem when using normal poser figures and props because it is easy to get visually confused about which axis is pointing in which direction. This prop makes all that VISIBLE, and just might help solve a problem that has bugged Poser users for several years. Let me know what you think - and if anybody is listening at CL - it sure would be nice to at least make the 3 axes behave the same (using GLOBAL or LOCAL values) but NOT some confusing mish-mash of everything. At least thats how it looks to me :-)

I don't know, the last time someone explained "gimbal lock" (or at least, the last time I read about it) in the Forum, I thought they did a good job. If NASA can't solve it, I'm not sure CL can.

(That came out snottier than intended. I do admire the trouble you've gone to to make this problem concrete. Who knows, maybe you'll find a new angle on it.)

Bill

Gimbal lock schmimbal lock. There's no excuse for Poser's behavior. Other 3D programs get it right. Thanks for your work on this.

Thanks Bill - at least for reminding me what the flim-flam term for it was. :-) - But just because they gave "gimbal lock" a name doesn't do much for fixing it. And the last time I looked, Poser was a 3D model posing tool not gyroscope or a Rocket Ship, and it certainly doesn't take a rocket scientist to notice that any $30 3D modeling program doesn't suffer from "gimbal lock" so why does Poser? Sorry folks, but regardless of what some say, writing code for 3D modeling is NOT rocket science, and there is really no good excuse for this behavior!

ronstuff,
I forget who it was but a couple of months ago or so someone was trying to rescale in an animation and ran into this or a similar problem.
Apparently, at least in Poser 4, there was no simple solution. There is some utility from DAZ(?) I think that was supposed to address this.(not sure - I think it's called Scaler(?)) If the member that was working on this doesn't chime in, you might try to find that thread in the archives. Try under scale or scaling. Sorry not to be of more help.

• TJ

Thanks bikermouse (any relation to bikerHouseMouse?) I'm not a newbie, and I am fully aware of all the previous attempts to explain this. My testing has led me to believe, however that it is all hogwash because people can't see the fundamentals at work in a complex object like a human figure with numerous parts, each of which has a Local axis which can be manipulated in the setup room. The confusing behavior has led to some wild speculation, not all of which is technically correct. For the first time, using this very simple device, the real error becomes clear and highly visible - unencumbered with other "possibilities". The code for rotating the Y axis is FINE. There is NO reason for the other two axes to be any different except for a faulty algorhythm. If this is CL's INTENTION, then they should SCRAP it and go get some of the free 3D code that is in the public domain, from which several inexpensive 3D packages have been written, and which all works FINE. As long as the Poser community tolerates it, CL will probably continue to hide behind the "gymbal lock" smokescreen. In which case, I look forward to DAZ's posing tool because I can assure you even without ever having seen it, that props will rotate properly!

Sorry, it's not a flim-flam or a smokescreen, it's a well-known problem for any rotational matrix using orders of rotation and computing Euler angles. It's a straight kinematic problem and has nothing to with X-rotate being coded different from Y-rotate by CL.

You can find tons of documentation on this via Google. For instance:

http://www.edharriss.com/tutorials/tutorial_xsi_gimbal/xsi_gimbal.html

http://www.fho-emden.de/~hoffmann/gimbal09082002.pdf

http://wiki.beyondunreal.com/wiki/Brush_Rotate

http://art-design.smsu.edu/yarberry/Courses/Reference/PivotPoints/

http://www.darwin3d.com/gamedev/articles/col0398.pdf

Now, does Poser have to use Euler angle computation? No, here you're right, there are other ways to go that don't gimbal lock. But there may be good reasons why CL did not go with the alternative (Quaternions, also called Euler parameters -- different from Euler angles). There's a detailed discussion of exactly that subject here:
http://isb.ri.ccf.org/biomch-l/archives/biomch-l-2001-05/00018.html

And this link claims (I don't own any of this software, so I couldn't tell you one way or the other) that Poser is far from alone among 3D programs that use Euler and get gimbal locked. Says the same thing is true of Maya, Max, Lightwave, and Softimage:

http://www.anticz.com/eularqua.htm

Bottom line: there's some kind of tradeoff between gimbal lock on the one hand and problems interpreting anatomical biomechanics on the other. Since Poser is all about anatomical biomechanics, they chose to live with gimbal lock. A drafting program would go the other way.

It's not messed-up code, though, and assuming otherwise isn't going to get you anywhere.

Bill

Thanks Bill, I really appreciate the links and the concise summary. It is a shame that there is no simple resolution to this problem. Maybe some day there will be bright young mathematician who will discover another way of doing it that offers the best of both worlds. Since my background is mostly with CAD and object oriented modeling, I have never encountered this problem, even though I have done some fairly complex animations. It surprises me that you mention MAX as being in this group because I have used it quite a bit, but have not had the opportunity to observe gymbal lock. I'll read up on the links you have provided, and get back to you with any questions :-) thanks again

Good heavens, ronstuff, thank you for taking my post in such a good spirit. If more people could discuss their pet ideas with such open-mindedness and courtesy, 'rosity would be a much happier place.

And thank you for bringing the subject up again. Before, I was just content with understanding why gimbal lock happened within the Poser system. Your post forced me to ask the (come to think of it, obvious) question, "Why does Poser use this system? Aren't there others?"

And that's still a good question. Trying some more refined Google searches linking those 3d software programs with "gimbal lock," I'm beginning to get the impression that a lot of them have found various ways of finessing gimbal lock problems that were more prominent in earlier versions. (Maybe Max is one of them.) So maybe there's hope for Poser.

And as far as the tradeoff -- the problem Poser avoids by living with gimbal lock -- so far I've only seen little hints of what that is. I'd love to know, and I'm sure you would too. I think we are most likely to find it by following up the medical biomechanics links; apparently the doctors who reconstruct shoulders and hips face a similar tradeoff when trying to model those joints.

I had a tooth extracted today, so I literally have a hole in my head and am probably not going to learn anything more about this tonight. I didn't mean to leave the false impression that I actually understand Euler angles or Quaternions from a math standpoint (or any other standpoint) -- I was just summarizing the articles I saw in Google. With your CAD and programming experience, you will probably get more out of those references than I do.

But if I do turn up anything on the nature of the tradeoff, I will post it here. And I'll be very interested in anything you learn about this as well.

Thanks again for making this a real dialogue and not battling rants.

Bill

I have to say this feature drives me mad on frequent occasions. Using gimbal thingummy may be convenient for anatomy, but if you are trying to get a prop in place, it screws up bigtime. The smart solution would be to have optional rotational parameters: e.g. a dial for "rotate local X" and another for "rotate global x". Part of the problem is the schizoid nature of Poser. On the one hand, you can argue that it is designed as a figure creation tool ONLY and that all scene manipulation and rendering should be done in another app. On the other hand, Poser is clearly being positioned as an all-in-one tool, while clearly lacking the facilities for being a good one. Improving the render engine is in vain when the basic tools are screwed up.

Why don't you just use this handy tool? With the Direct Manipulation tool, you don't have to worry about rotation order or gimbal lock any more. Euler angles have a problem with rotation order and gimbal lock, period. If you want the x,y and z paramters of the rotation as seperate input fields, you have to live with that. 3ds max 5 has that problem too - use the input fields for rotations, enter 90 degrees in the y field and then try to enter values in the z field - surprise. With a rotation order of XYZ, a 90 degree rotation will align the x and z axis and take you one degree of freedom. In-depth mathematical explanations can be found all over the net, if you want to dive into it. Quaternion representation is a mathematical solution, but none you would want in a text input field. Quaternions are four-dimensional normalized values - (0, 0.7071, 0.7071, 0) is not a very intuitive representation for a 90 degree rotation, is it?

A quote from a link wadams9 posted:

" If your going to use Eular angles (and every 3D package has them somewhere) your going to have problems with gimbal lock. The only advantage to using Eular angles is that they are much easier for an artist to read and conceptualize than a Quaternion Rotation."

Poser uses quaternions for animation interpolation when desired (menu Animation/Quaternion Inperpolation) to avoid some other problems Euler angles have, and you can access quaternion rotation values via Python.

stewer, wait a minute :). Does Poser use Euler angles or Quaternions or both? Why don't they just use quaternions for all rotations (not just animation interpolation, as it appears by your statement)? Despite their non-intuitiveness, there are algorithms to convert between the two systems of rotation so that the user doen't have to deal with quaternions directly (gets back Euler angles, but no gimbal lock).

Oh, check out the "Graphics Gems" series for a list of varied articles on Quaternions, some by the "father of quaternions", Ken Shoemake. Not saying that it's easy reading though.

Perhaps it is just me but I have not had rotation problems with Posers "on board" props, at least that I can recall. I do frequently have rotation problems with imported props. Stewer's above solution is the least frustrating way to deal with the problem. I can usually use the direct manipulation tool to rough in the rotation, then observing the new dial settings, finish the positioning. I feel sorry for newbies who first encounter this very frustrating "feature".

I don't care, and shouldn't have to, how Poser gets from position A to position B internally. What I do care about is the user trying to manipulate an object. For some users just getting x,y, and z straight in their heads is hard enough. If you've got BODY selected, why should rotation order even enter into it? I understand the problem with an arm, but not a shoe you are trying to fit as a prop.

Attached Link: http://www.anticz.com/eularqua.htm

*Does Poser use Euler angles or Quaternions or both? Why don't they just use quaternions for all rotations (not just animation interpolation, as it appears by your statement)?*Just like probably any 3d application on this planet, Poser is internally using 4x4 matrices for rotations. The question is what values do you present to the user - and since most people think in 3 axis rotations rather than fourdimensional complex numbers, Euler angles are what the parm dials use. As soon as you have three text fields or parm dials with x, y and z rotation you will have to deal with rotation order, you can't avoid it.

Rotation order is not a Poser specific problem. Read the link wadams3 posted (I attached it to this post), it does a good job of explaining that.

Use the direct manipulation tool and get over it.

What direct manipulation tool? Never seen it. Is this a pro pack thing?

If you want to try for yourself:

Pick up a book. Hold it in front of you, upright with the cover facing you. Now think of fixed x, y and z axes in your room, with the same orientation as in Poser: x pointing to the right, y up, z in your direction.
Rotate the book by 45 degrees around the y (up) axis. Then rotate it by 90 degrees around the x axis. Remember its position.

Now put it back in the initial position. Rotate it by 90 degrees around the x axis. Then rotate it by 45 degrees around the y (up) axis. Note how you get a different result than before - rotation order does matter, even without a single line of code.

We were just using world space rotations, now let's try if local axes are better. Let's not use a book but your right hand thumb, index and middle finger - forming a right hand coordinate system with the thumb being the x axis, the index finger being y and the middle finger being z, see the picture.

Now rotate 90 degrees around the thumb (x), so that your palm points upwards and the index finger away from you. Then rotate 90 degrees around the index finger (y), so that the middle finger points to the left and the thumb points up. Remember that position.

Back to the inital position, x right, y up and z at you. Rotate 90 degrees around the index finger (y) - thumb pointing at you, middle finger to the left. Rotate 90 degrees around your thumb, same direction as before, putting your hand in a position with your index finger pointing to the left and the middle finger upwards.

Again, rotation order matters. We did the same rotations as before, only in different order.

Phtast asked- What direct manipulation tool? Never seen it. Is this a pro pack thing? A: In stewer's post #11 he has a screen shot of the DM tool in action. Notice in the upper right hand conrenr of the screen shot a little M&M with an image of a circle with three arrows? That's how you toggle on the DM tool. It's only in Poser 5, not Pro Pack. It allows translation, constrained rotation, free rotation and scaling by directly manipulating the one of the arrows, the elipses or the object itself. I was one of those rare P5 manual readers (page 172) that was pleasantly surprised when I discovered the Direct Manipulation tool.

Also Body scales work in world space while part scale work in part space. What this emans is if you take a figure and body scale it to 110% on the x axis then turn it 90 on the z axis you'll see it get longer and thinner. Now CL coudl have used quaterions for the rotation and this would have solved a few things but probably their reasoning was eulerrotations would be OK because most work in poser is table top work meaning most things are on a flat stage and heading and roll are more important than pitch. Poser is NOT Max or Maya. Its more of a toy in that respect.

I just wanted to pop in here and say this is a damn good thread! I am going to need another cup of coffeethough before I read it again. Too much math, LOL

Stewer, I understand. As a programmer who has dealt with 3D graphics programming, I know all about Euler angles, order of rotation, and gimbal lock. Because quaternions aren't dependent on the "order of rotation" (and therefore don't suffer the gimbal lock problem), they are the best choice. Not the most understandable, but the best. As I said, there are ways to convert between Euler angles and quaternions, so the interface doesn't matter. You can specify Euler angles in the interface and convert to quaternions for the actual rotation in order to avoid gimbal lock. As for "trackball" rotation, there is a full algorithm developed by Ken Shoemake that allows full rotation without gimbal lock. I've heard that it requires a little practice as it is not entirely intuitive. Mason makes a good point (that others have made also) that CL probably didn't incorporate quaternions because it just isn't a necessity - and maybe too much work ;). Other 3D apps, like 3DSMax, have a work around for gimbal lock and as stewer mentioned, still use Euler angles. On the other hand, many games use quaternions (at least from what I've read).

stewer: Just like probably any 3d application on this planet, Poser is internally using 4x4 matrices for rotations. The question is what values do you present to the user - and since most people think in 3 axis rotations rather than fourdimensional complex numbers, Euler angles are what the parm dials use. Actually (even acknowledging that you have access to the source code) its not just a matter of what is presented to the user, but is also dictated by the need for to define scalar values for animation interpolation purposes. Both quaterions and matrix rotational forms contain an inherent normalisaton factor, which would be invalidated by applying a simple spline interpolation curve to individual parameters, resulting in scaling inconsistencies as objects were rotated. Alternative mechanisms for interpolation such as the interpolation path defined in three dimensions (plus twist) around the surface of a sphere centred on the object origin, which is essentially normalised quarterion interpolation, could be implemented. However these would still create representation problems. While Quaterions and homogenous matrices are both superior representations, and rotational axis (Eular angles) can be translated directly into these forms, the reverse translation can result in undefined (rotation) values, specifically at the point when the axial rotations demonstrate gimbal lock. The presentation of the axial rotation values in an animation graph would have to accomodate undefined values and direct manipulation of keyframe values (after translation into another form and back again) would give some fairly difficult to predict results. In fact Poser, I suspect (as indicated by the keyframe parameter channel data in the files) stores and interpolates only axial rotations, but (as with all applications) translates the rotations into a matrix format for 'on-the-fly' when needed for geometry calculations. As such the matrix values are only an intermediate step in world space transformations. This, unfortunately, prevents them from being used to overcome the problem, as the actual matrix coefficients are, in all circumstances, dictated by axial rotation angles, with all the problems inherent in that representation. Bill

What he said.

For anyone just skimming this thread (which really did turn out to be very informative), the bottom line is:

Gimbal lock is very common in 3d programs, not a CL "bug", but in Poser 5 you can use the Direct Manipulation tool to get around it.

(My personal thanks to stewer. I knew about gimbal lock, I owned Poser 5 -- and I had completely missed the value of the Direct Manipulation tool.)

On the subject of 'rotation order', I came across this problem recently in a big way. I discovered that, in the furniture figures I had been building, using the Rotate Tool sent all the doors and windows in every direction (well... in 2 directions) and the Twist tool was almost useless. Thanks to VK, I figured it out and. since most of the doors and windows use the Y rot, I took his advice and switched the rotation order of the dials in the cr2s, putting the Y rot first. Like so... Y rot X rot Z rot I then set the limits on the X rot to zero, so now everything rotates perfectly with the Twist tool, and the Rotate tool affects nothing, thereby avoiding the 'flying window' syndrome. If the user wants to, they can open the rot dials and set any limits they need. It's all a bit klunky though. Bad when you have to resort to these measures. mac PS I did notice that on BODY, Y rot is always the first dial, but on any other body part, it's X rot. Strange....

Does the QUATERNION_ON 0 line in Poser.ini toggle the use in animation as mentioned earlier?

Attached Link: http://www.hdm-stuttgart.de/~sw19/files/eulerquat.swf

One thing before this gets into a wrong direction: Euler angles are not bad by definition, and in character animation, chances are you want to use Eulers over Quats. Why? The problem that Quaternions have is that when interpolating rotations, it always takes the shortest and direct way and does not give you any way to preset a preferred direction the rotation should take.

I made a small movie clip to show the difference between Euler and quaternion rotation:
Both arms have only two keyframes, no rotation in frame 0 and 90 degree bend and 90 degree twist in frame 30. The Euler rotation is what you would expect: In frame 16, both bend and twist are at 47 degrees. However, in the quat interpolation, twist and bend are both at 34 degrees and front/back is at 18 degrees. I never told the program to rotate front/back, but quaternions make it do that. This is why, despite all the problems, you most probably want Euler angles in character animation - your paramters are not anonymous and interchangeable xyz any more but bend and twist.

ronstuff, No relation - unless you subscribe to the hypothesis that an asteroid brought microscopic life to Earth from Mars - even then very distant relatives at best. Just like to see it when a mouse makes good! Not sure about all these mousetraps that are showing up in free stuff though! I hate stepping on those things - always seem to break a toenail on them. All, This has turned out to be an interesting discussion . . . gonna save this one. stewer, nice example!

GREAT DISCUSSION :) I agree with Phantast: "...solution ... optional rotational parameters: e.g. a dial for "rotate local X" and another for "rotate global x"." For a single pose (picture) it doesn't matter what the math is internally - just have the program calculate whatever numbers it needs to reach the requested position. In this case, it is purely a matter of creating a user interface that gives the user the control they desire. For an animation - quaternions versus Euler angles - it isn't like Poser provides any way to control what path it takes - it always takes the path determined by its ordering of the 3 angles. This is no better than the quaternion solution - it just fails in different situations. In either math approach, what is needed, as was mentioned, is some way for user to SPECIFY what path is desired. (With either approach, the bad cases can be improved by adding more key frames.) I don't have enough experience to prove it, but it should be possible with quaternions to get any desired path by specifying the direction to be moving in at each key point, similar to defining a spline path through space. That is, quaternions deal with ROTATION change in a way that allows well-developed solutions for POSITION change to be used. Euler angles do not have such desireable properties. What I'm saying is that quaternion-based applications will eventually offer superior user-interfaces for animation. (Maybe they do now - I can't afford any of the high-end stuff...) - - - - - - - - - - The Direct Manipulation tool in Poser5 looks like it does useful math - turn one of its rings, and see how Twist, Side-by-Side, and Bend change for a given body part. Personally, I have trouble with the DM tool. I end up clicking on a body part when I don't want to - especially when trying to do a freehand movement. I also have trouble doing the freehand movement I want - it doesn't seem to act like a trackball - I often get a rotation in the plane of the screen (like hands of a clock), when I am trying to pull a figure head-over-heels. The end result is that I never bother using the DM tool. A shame, as it is such a promising idea... - - - - - For many uses, I find dials easier for precise results. So while we're wishing, I wish there was a "3 dials" version of the DM tool. Or at least, a DM tool that disables part selection. For example, hold down ctrl if want to pick new part, otherwise, stays with current part.

"Or at least, a DM tool that disables part selection. For example, hold down ctrl if want to pick new part, otherwise, stays with current part. " Ooooh, brilliant. I like that. It's really a great suggestion so, um, please submit it to CL?

For many uses, I find dials easier for precise results.
So while we're wishing, I wish there was a "3 dials" version of the DM tool.
This would only work for relative rotations, absolute values will give you all the problems Eulers have.

Or at least, a DM tool that disables part selection. For example, hold down ctrl if want to pick new part, otherwise, stays with current part.

Holding the shift key will lock the current selection, try that.

On a side note: I could produce gimbal lock in 3dsMax 5, Cinema4D XL7 and a demo version of Maya 3 by simply entering 90 degrees in the y rotation field. 3dsMax even has the bad habit of changing the xyz values after you press the enter key. Face it, as soon as you enter your rotation in x, y and z angles, you will have to deal with gimbal lock, no matter what you use internally.

Well, I didn't read all of the above, but Gimble lock is a load of old tripe - use Quaternions instead of axisangle you dumb poser programmers.