Re: [eigen] Rotations and unit vectors

[Hauke Strasdat <strasdat@xxxxxxxxx>]

> However, functions such as toRotationMatrix() or q * v give undefined (or
> unintended) behavior for non-unit quaternions).

One geometric interpretation of a general Quaternion class would be the group of rotation and scaling. 

I submitted related patches some time ago:

http://eigen.tuxfamily.org/bz/show_bug.cgi?id=459

Regards,

Hauke

On Fri, May 17, 2013 at 5:56 AM, Hauke Heibel <hauke.heibel@xxxxxxxxx> wrote:

Hi,

I started adding some trivial tests over here: https://bitbucket.org/hauke/eigen_geometry_asserts

As you will see, I did not yet touch the Quaternion class. The reason is that it already allows partial usage as a non-unit Quaternion as Gael mentioned (there exists e.g. a function void normalize()).

- Hauke

On Fri, May 17, 2013 at 12:31 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 17.05.2013 10:45, Gael Guennebaud wrote:

Even though there is a related bug entry, I continue here to give it
more visibility.

I added a dependency between these bugs, but also continue detailed discussion here.

Actually, a quick look at the current Quaternion class make me think
that we should be able to generalize the current Quaternion class to
be of general purpose without breaking or penalizing existing code.
Only a few members would be marked as deprecated with an advise to
move to the UnitQuaternion class. They include:

Yes, deprecating some of the methods is probably the way with the least harm.
The alternative would be to introduce a new class GeneralQuaternion and define the current Quaternion class to be a unit Quaternion (with assertions) -- this would most likely effect much less users, but we will give up API compatibility for them.

- conversions from/to rotation matrices

I would not see a problem with conversion from rotation matrices. The same as I would of course allow "conversion" from UnitQuaternion to Quaternion.

- slerp
- setFromTwoVectors
- angularDistance
- operator*(vector)

We should also think about the conversion from Quaternion to
UnitQuaternion. For instance:
  - Shall Quaternion::normalized() returns a UnitQuaternion? I guess not.

I would not see a problem with that, as the back-conversion to a general Quaternion is free. Actually, I would see this as a very clean way to initialize a UnitQuaternion from a non-unit 4d-vector:
  UnitQuaternion q1 = Quaternion(w,x,y,z).normalized();
// And if w,x,y,z are known to be normalized already:
  UnitQuaternion q2(w,x,y,z);

Actually looking at that, I see a unique opportunity to change the inconsistency:
  Quaternion(w,x,y,z)==Quaternion(Vector4(x,y,z,w))
I.e., we could make the new UnitQuaternion behave the same way for initializing from data pointers and from 4 scalars (but we would need to introduce another class for the GeneralQuaternion, as well)
However, I'm afraid that changing that would (at least temporarily) add more confusion than it solves.

  - The conversion from a Quaternion to a UnitQuaternion should
probably trigger an implicit normalization that could be avoided via a
Quaternion::asUnitQuaternion() cast function?

Hm, not entirely sure about the implicit normalization. By the same reasoning all constructors should implicitly normalize (instead of assert, as currently proposed). I would slightly prefer to only assert unity when assigning Quaternion to UnitQuaternion -- but I'm not entirely fixed on that opinion.

Regards,

Christoph


--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------