| 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