Euler angles vs. Quaternions - problems caused by the tension between internal storage and presentation to the user?

Question

Quaternions are arguably an appropriate choice for representing object rotations internally. They are simple and efficient to interpolate and represent a single orientation unambiguously.

However, presenting quaternions in the user interface is generally inappropriate - Euler angles are generally much more familiar to users, and their values are a little more intuitive and predictable.

Euler angles suffer from being complicated at the code level - they require that an order of rotation is stored, and composing a practical orientation (be it matrix or quaternion) using this order and associated angles is cumbersome, to say the least.

Reliable interpolations are most conveniently performed using quaternion representation - so does this mean we must convert constantly between an Euler representation and a quaternion representation? Is this feasible in terms of performance?

Can we store the orientations as quaternions and convert them only for displayed to the user? This may not be possible because for any given orientation there is exactly one quaternion representation but many Euler representations. How do we 'pick' the Euler representation that corresponds to the one that originally defined that orientation? It seems like an impossible task - we've effectively lost information when converting to a quaternion.

Could we store as Euler angles and then convert to quaternions as needed? This probably isn't scalable - conversion from an Euler angle to a quaternion, interpolation, and then conversion back again is likely to be relatively expensive code.

Could we simply store both representations and use the most appropriate for any given situation? A large cost in terms of memory (imagine animation curves for a skeleton with around sixty bones) and keeping these values synchronised could be expensive, or at least cumbersome.

Has anybody seen, used or though up any clever solution to this problem? Surely the three options above aren't out only ones? Are there any other problem domains similar to this that have been solved?

Solution

You asked this question 12 years ago and I am telling you the answer you checked is completely wrong. That guy doesn't know what he's talking about.

If you restrict the domain of Euler Angles (let's go with yaw pitch roll) to -180 to 180, every single quaternion has at least TWO sets of YPRs (yaw pitch roll) that represents it. There is NO WAY to know which YPR is correct without additional assumptions.

The best solution is to ALWAYS store YPRs internally then when you need to do a computation, convert the YPR to a quaternion. That is the proper answer.

Doing computations with quaternions will again yield multiple possible solutions however because you only stored the YPR internally you will be able to use the original YPR to help you find correct YPR that was derived from the Quaternion.

That guys 3 decades of experience doesn't mean jack. Most likely he's dealing with a restricted system. If 2 axises or more of rotation are restricted to only be able to sweep 180 degrees (-90 to 90 in this case), THEN and only THEN will there be a single YPR represented for every quaternion. Because the guy is an aerospace engineer I am pretty sure that's what he's dealing with since physical gimbals usually have restricted angles of rotation.

Comments

[zahni123]

If only :) But I'd be surprised if you could get away with it in practice. As far as I'm aware, normal workflow for a 3D artist will almost always involving knowing the actual numbers - so while you might provide them Max/Maya style rotation gadgets, at some point they're going to want that rotation to be exactly 30 degrees, or at least see exactly what that rotation is.

[zahni123]

You mean store as quaternions and convert to Euler angles as needed? Because of the reasons I outlined above - there are many Euler representations for a single orientation... which one do you present to the user?

[zahni123]

I'd love to get away with that, but I suspect in practice the 'simplest' Euler angles are almost as difficult for an artist to deal with as quaternions (in that they aren't always intuitive). Animation data presented as curves would present a particular challenge I think, as it may look quite different from what the artist expects.

[Derek E]

Why don't you pick a convention? Say two rotations in the lab frame and one rotation in the body frame. This requires you to keep body coordinates for every object, but an artist might like that.

[SingleNegationElimination]

10 bodies with 50 members each is 500 members, times 72 fps is 36000 conversions. Not very many. You could do 1000 times that and still be using very little cpu

[zahni123]

That's a good point. Maybe it really needs to be profiled before writing it off as a solution. But it just seems so inelegant to have to convert constantly! Incidentally, it isn't 10 separate characters with 50 bones, it is a single character with 10 animations active at the same time and blending between them (i.e. a walk with a fast walk and an upper body turn). But I suspect the calculation is the same.

[Baumflaum]

Assuming you don't need the exact YPR values but only the resulting rotation: why would you introduce ambiguity/complexity(assuming YPR/specifying YPR at every step) into your system in addition to a greater computational load? In most applications you need the resulting orientation so the exact YPR values do not matter. Also converting Euler angles into different coordinate systems as required with robotics does not sound fun.

[Brian Yeh]

@baumflaum quaternions are a fantasy value like imaginary numbers. If I want to present a real rotation to a physical gimbal, I have to give that gimbal a YPR. Each motor on the gimbal needs to know how many radians to turn. A quaternion is useless in the physical world. A physical gimbal restricted to -180 to 180 on all axis has two YPRs for each quaternion. This is not a math trick.

[Brian Yeh]

@baumflaum The physical gimbal itself for each orientation the motors have a total of 2 sets or YPR rotations that can achieve the identical orientation in space. The is important because whatever rotational configuration the gimbal is in it's relative thresholds to it's max range of motion is different. Quaternions mask this duality in the physical gimbal. If you restrict pitch from -90 to 90 for ypr, this duality no longer exists.

[Brian Yeh]

@baumflaum The robotics systems you've dealt with have likely did this... If this is done then yes... There's a one to one mapping from positive unit quaternions to restricted YPRs and a library can abstract away the need to touch YPR (although ypr is still the command sent to the motors) Check your robot gimbals. One axis must be specially restricted to a 180 degree sweep, while the others are open to 360 degree sweeps.

[matthias_buehlmann]

Sorry to say but this is completely wrong. Your gimbal is just your specific implementation of the orientation control. You should convert from and to that specific implementation only at the interface level. The fact that any orientation can be represented by one canonical Quaternion but multiple YPRs is a problem of Euler angles, not a problem of Quaternions (they are in fact the solution to that problem, exactly as with gimbal lock).

[Brian Yeh]

You're not understanding the concept. Multiple YPR configurations happen in REAL LIFE. That means a physical gimbal can point at a SINGLE orientation, but the rotational mechanisms can HAVE TWO DIFFERENT CONFIGURATIONS to achieve that. This configuration information is often needed as the range of motion is effected depending on the configuration of the rotational mechanisms. (20, 20, 0) = (300, 160, 180). In the preceding example the 2nd equivalent euler angle is nearer to the end of the range of motion. Quaternions unfortunately, HIDE this information.

[Brian Yeh]

@matthias_buehlmann forgot to tag you above. Anyway it's very easy to see the problem. Imagine a gimbal in real life that takes a quaternion as input and rotates it's motors to achieve the orientation picked by the input quaternion. Let's say you input a quaternion equivalent to the euler angles: (20, 20, 0) OR (300, 160, 180). Which euler angle does the gimbal pick? It's ambiguous. Because the quaternion doesn't hold enough information.