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?

Answer 1

I am an aerospace engineer; I have been using quaternions for spacecraft attitude control and navigation for going on three decades. Here are some thoughts on your situation:

1. Performing any kind of process that changes orientation with Euler angles is verging on impossible. Euler angles suffer from singularities - angles will instantaneously change by up to 180 degrees as other angles go through the singularity; Euler angles are virtually impossible to use for sequential rotations. Quaternions do not suffer from either of these problems
2. There are 12 different possible Euler angle rotation sequences - XYZ, XYX, XZY, etc. There is no one "simplest" or "right" set of Euler angles. To derive a set of Euler angles, you must know which rotation sequence you are using and stick to it.
3. I suggest you perform all storage and rotation operations with quaternions and only convert a quaternion to Euler angles when output is required. When you do this, you must define which Euler rotation sequence you are using.

I have algorithms for all these operations and many more: quaternions to/from Euler angles of any rotation sequence to/from rotation matrices (direction cosine matrices), quaternion interpolation matching position, rate, etc. at end or intermediate points, rigid and flexible body dynamics and kinematics using quaternions.

Please contact me if I can be of assistance at [email protected]

Answer 2

I am a fan of quaternions. In order to make them work, could you reconsider your presentation to the user? Instead of presenting the rotation to the user as a series of Euler angles in text form, you might instead pick some simple 3D object and apply the quaternion rotation to the object to display visually the rotation in effect.

Answer 3

Why not use Quarternions in code and convert the Q to angles when needed for display ?

Answer 4

You can represent the rotation as axis + rotation angle, which is essentially the same as quaternion (up to a sign)

Answer 5

I don't think it makes sense to use Euler angles internally - you'll want to use quaternions for all your calculations and usually won't be able to afford the conversions going on everywhere. As for the converting it back to Euler angles for the UI - would it be that bad if the user only gets an angle that is equivalent to the original input but is represented differently? If you do the conversion right, you should end up with the "simplest" Euler angles for any given quaternion.

Answer 6

How many conversions are we talking about. It looks like you're paying for about two transcendental operations per conversion, which on modern hardware is available in the order of 100millions per second. I'd store both, Quaternions for accuracy and aesthetics and euler rotations for preserving user info. Maybe add a flag to indicate which is preferred for any given object. On top of that, you only have to perform the conversion once per rotated member. Once you've computed a transformation matrix, its multiply-adds until you run out of vertexes.

Answer 7

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.