Re: [eigen] Rotations and unit vectors |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: Re: [eigen] Rotations and unit vectors*From*: Hauke Strasdat <strasdat@xxxxxxxxx>*Date*: Fri, 17 May 2013 10:08:06 -0700*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=Qsim7hSeVr6cK+d0bGgR9FOJGOnJYYZfl01Fmx1SJvI=; b=i7i6eHCta4PSu66uY+Yu0saerhybJyTQgDJROa7npPjuTs31ht0RqQqy6QKiqNG2IU EPwubq6E2XjhCY7QdvqG2Bc/85Dd45z/PpFGYdNYBsXHv9l0yKTb99tbGXsMhLtlBRug 9mZ7p0n8hM7mV8jTuRssPT/uZmOv/4S3IYw5vEwGR9R1IdtnVjEQNkpBFcNGGTHmU3in vRYW0nROEPYEGyZ8mK7hsxgMYjtQJ3csnBioVFf9vv8VHo6mHZS3UZwaVGFYiH4frL5Q dXc0K00f3UCXzUtEhLnTf8niUt/nb9GLRD8r+a/3M0rS/u/gfrClErwsVlQQ8n17zQAL UN4g==

> However, functions such as toRotationMatrix() or q * v give undefined (or

> unintended) behavior for non-unit quaternions).

> unintended) behavior for non-unit quaternions).

I submitted related patches some time ago:

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_assertsAs 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()).- HaukeOn Fri, May 17, 2013 at 12:31 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 17.05.2013 10:45, Gael Guennebaud wrote:I added a dependency between these bugs, but also continue detailed discussion here.

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

more visibility.

Yes, deprecating some of the methods is probably the way with the least harm.

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:

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.I would not see a problem with conversion from rotation matrices. The same as I would of course allow "conversion" from UnitQuaternion to Quaternion.

- conversions from/to rotation matrices

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:

- 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.

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.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.

- The conversion from a Quaternion to a UnitQuaternion should

probably trigger an implicit normalization that could be avoided via a

Quaternion::asUnitQuaternion() cast function?

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

----------------------------------------------

**References**:**[eigen] Rotations and unit vectors***From:*Hauke Heibel

**Re: [eigen] Rotations and unit vectors***From:*Robert Lupton the Good

**Re: [eigen] Rotations and unit vectors***From:*Benoit Jacob

**Re: [eigen] Rotations and unit vectors***From:*Andreas Keil

**Re: [eigen] Rotations and unit vectors***From:*Christoph Hertzberg

**Re: [eigen] Rotations and unit vectors***From:*Gael Guennebaud

**Re: [eigen] Rotations and unit vectors***From:*Christoph Hertzberg

**Re: [eigen] Rotations and unit vectors***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rotations and unit vectors** - Next by Date:
**[eigen] Blocks and EvalBeforeAssign** - Previous by thread:
**Re: [eigen] Rotations and unit vectors** - Next by thread:
**[eigen] Error: trying to recover Q matrix in sparse QR factorization**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |