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*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Fri, 17 May 2013 10:45:08 +0200*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=UNrOpxC/4Er328YjcUJTlO/HHxrFUPbWTlGH7OUNNkg=; b=dMdFE1YUG5aNDft3zdzfhfflHSA0B4g1G4Kc5lNGINJwQ/qC6MsSz+VRSyY6jEcbcu UjVAfSVBPxVAXwNHzRkfBNbSexx+FttcuvGKPFmImHBmA4fM/jjmdivdWfrWpxtFG99o cxuUewnYBpNyJCT8YomR/IlmrWPKjSjhw9gbzF0xxnsc2M+IrElIHYG10JN+1Yw6eGQ6 tLuLsLSjRdgSafl84/FcI5x4WmSeG0YLz97+I89Gf6b/UX6GG5wAckq6O45b+MaNdCTU OxDJqxRufWMCxTMYIglupnTS5Awif5ixrLkm1y1t8TJrvbdPQlByve74AfnvFRqjFpcW NyWw==

On Tue, May 14, 2013 at 6:14 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > W.r.t. Quaternion there is the problem that it is only somehow intended to > be a unit quaternion but never explicitly named so. > There are also users who like to use non-unit Quaternions: > http://eigen.tuxfamily.org/bz/show_bug.cgi?id=560 Even though there is a related bug entry, I continue here to give it more visibility. > If it actually was a unit quaternion, then normalize(), normalized(), norm() > and squaredNorm() could be essentially NOPs/accessors/const-expressions, and > inverse() would be just an alias for conjugate(). > > However, functions such as toRotationMatrix() or q * v give undefined (or > unintended) behavior for non-unit quaternions). > > I'd like to vote again for adding a new class UnitQuaternion which does > run-time checks for unity (and exploits all reasonable optimizations) and > either deprecate the current Quaternion class to introduce a new class > GeneralQuaternion, which works as suggested in bug 560, or let the current > Quaternion class behave like a general quaternion. > That also means that q*v shall return (q*[0;v]*q.conjugate()).vec() or > should not be implemented at all. > > Unfortunately, I think that deprecating/deleting/redefining Quaternion is a > rather heavy step and at least deleting/redefining must wait until Eigen > 4.0, to ensure API compatibility. 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: - conversions from/to rotation matrices - 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. - The conversion from a Quaternion to a UnitQuaternion should probably trigger an implicit normalization that could be avoided via a Quaternion::asUnitQuaternion() cast function? cheers, gael

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rotations and unit vectors** - Next by Date:
**Re: [eigen] Rotations and unit vectors** - Previous by thread:
**Re: [eigen] Rotations and unit vectors** - Next by thread:
**Re: [eigen] Rotations and unit vectors**

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