Re: [eigen] Quaternion toRotationMatrix

[ Thread Index | Date Index | More Archives ]

Hehe, thanks, ok, there is already lots of discussion about this...

Hm, is there already any consense? What is prefered?
I liked the so far implementation, also because  a quaternion handled by numerics never stays really unit, and the user can normalize when ever he wants...

OK, so sofar Quaternion rotation is implementet like christoph stated (DEFAULT), so to clarify the behavior in discussed

Summary ( s = squarenorm of quaternion q) :

rotate (DEFAULT == EQUATION 1.110):

    res = q*[0;v]*q.inverse() = 1/s * q*[0;v]*q.conj();   // what Michael and many others want (ALWAYS A ROTATION even IF non-unit)

that is exactly equation 1.112

    res = q*[0;v]*q.conj() = s * q*[0;v]*q.inverse()     // cf Bug 459 ( IF non-unit -> rotation with scale s, IF unit -> only rotation)

that is exactly equation 1.112   and the same as    rotateAndScale

    res = q*[0;v]*q.conj();

so the quaternion rotation operation so far in eigen3 is always a rotation no matter if normalized or not....


On 09/30/2015 06:14 PM, Christoph Hertzberg wrote:
This is basically what was suggested here:

The thing is (as you noted) that so far Quaternions are always assumed to be unit-quaternions, and silently introducing a division might give unnecessary overhead for some users. Our idea (which we never finished to decide on) was to introduce different Quaternion classes, which assume unity, or don't. Also see this and the dependent bugs:


On 30.09.2015 17:38, Gabriel wrote:

I have the following suggestions for the function *toRotationMatrix()*
for the *QuaternionBase* class:

The function is shown here:

The documentation says that this function is undefined if a non unit
quaternion is used! This is absolutely correct!

The function so far implemented is equation 1.112 in ( tilde is the skew-symetric matrix of a
vector  -> cross product)

If we want to use the Eigen function *toRotationMatrix*()   we need to
normalize the quaternion beforehand which is expensive!

A better way is to use equation 1.110 directly in, which directly normalizes the quaternion but
only needs the square norm of the quaternion "s"
which is much cheaper. Equation 1.110 directly gives a proper rotation
matrix! (orthogonal, and det(R)=1)

I would provide the following adaption:

*template<bool isQuaternionNormalized = false>**


*toRotationMatrix**<true>*       -> same function as already implemented
(user should use this if quaternion is already normalized)
**toRotationMatrix**<false>*      -> no normalized quaternion is given
as argument, use an implementation which uses equation 1.110 in

Maybe the default behavior should be "true" so there is no change to the
interface for the user who used these functions....

*BR Gabriel Nützi**

Mail converted by MHonArc 2.6.19+