views:

2027

answers:

6

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?

A: 

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
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
A: 

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

mP
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
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
A: 

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

A: 

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
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
A: 

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.

TokenMacGuy
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
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
TokenMacGuy
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
+6  A: 

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]

+1 win for being a pro
Stephen Furlani
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