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
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=560
Summary ( s = squarenorm of quaternion q) :
http://snag.gy/J6rDH.jpg
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)
rotateAndScale:
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)
rotateAssumeUnity:
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....
Gabriel
On 09/30/2015 06:14 PM, Christoph
Hertzberg wrote:
This is basically what was suggested here:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=458
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:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=560
Christoph
On 30.09.2015 17:38, Gabriel wrote:
*Hello,*
I have the following suggestions for the function
*toRotationMatrix()*
for the *QuaternionBase* class:
The function is shown here:
http://pastebin.com/QPRANVU6
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
http://snag.gy/J6rDH.jpg ( 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
http://snag.gy/J6rDH.jpg, 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>**
**QuaternionBase<...>::***toRotationMatrix*()*
where
*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
http://snag.gy/J6rDH.jpg
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**
*
|
