12

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?

starblue
  • 55,348
  • 14
  • 97
  • 151
Will Baker
  • 2,747
  • 4
  • 20
  • 17

7 Answers7

21

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 nhughes1ster@gmail.com

defhlt
  • 1,775
  • 2
  • 17
  • 24
  • 2
    Accepting this answer because it appears to have the most votes. However, 1) Yeah, unfortunately I'm working in the animation domain and artists expect to have Euler angles 2) Yep, and again animators expect to be able to set the rotation order on their bones arbitrarily so I have to support all permutations 3) That is more or less what I am doing in the end. – Will Baker Aug 17 '10 at 23:01
1

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.

Brian Yeh
  • 3,119
  • 3
  • 26
  • 40
  • 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. – Baumflaum Jan 28 '22 at 13:35
  • @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 Jan 29 '22 at 16:53
  • @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 Jan 29 '22 at 16:54
  • @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. – Brian Yeh Jan 29 '22 at 16:55
  • 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). – matthias_buehlmann Apr 19 '22 at 11:00
  • 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 Apr 27 '22 at 16:00
  • @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. – Brian Yeh Apr 27 '22 at 16:11
0

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.

Brian Ferris
  • 7,557
  • 5
  • 25
  • 27
  • 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. – Will Baker May 07 '09 at 03:54
0

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

mP.
  • 18,002
  • 10
  • 71
  • 105
  • 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? – Will Baker May 07 '09 at 04:00
  • 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. – Derek E May 07 '09 at 04:52
0

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

0

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.

Tal Pressman
  • 7,199
  • 2
  • 30
  • 33
  • 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. – Will Baker May 07 '09 at 04:36
0

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.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • This would be true if I was worried about a per-vertex cost or performing transforms for rendering - I'm mainly concerned with blending multiple animations together for a skeleton. So we're talking around fifty bones and perhaps 5 - 10 animations active at the same time. At this stage I'm hoping to store the animation data as quaternions, but I also need to present the animation curves as Euler angles to the user. – Will Baker May 07 '09 at 08:05
  • 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 – SingleNegationElimination May 07 '09 at 14:04
  • 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. – Will Baker May 07 '09 at 22:00