Re: [eigen] Rigid Transformations in eigen: discussion thread

[Rohit Garg <rpg.314@xxxxxxxxx>]

> I'm not sure that we want to abstract it and 'hide' the quaternion aspect..
> 1) this isn't what we have done with the Quaternion class
> 2) being able to access the underlying quaternions may be useful if
> the user was already using quaternions in his framework
Good point.
> 3) calling it DualQuaternion also makes room for other rigid
> transformation classes, should any appear. Like the Quaternion classes
> leaves room for there to be other rotation classes.
Fair enough.
>
>>> b) is there any use case, in 3D graphics, to add two dualquaternions?
>>
>> Google for the paper, "Dual Quaternions for Rigid Transformation
>> Blending". The transformation blending is implemented by linearly
>> blending dual quats and then normalizing. BTW, (linear
>> interpolation+normalization) is also the cheaper cousin of slerp for
>> quaternions, sometimes called nlerp.
>
> OK, that's sort of what I suspected: the only obvious way that adding
> (dual-)quaternions and multiplying them by scalars would make sense in
> practice.
>
> Then I would much rather have a specialized method nlerp() for that.

With a specialized nlerp() you can't go general blending, which is
needed while performing character skinning.

IE, operations like (w1*Q1+w2*Q2.....+wN*QN).normalize(), what about them?
>
> Meanwhile we do a trick as i discussed in previous emails to allow the
> user to easily address the underlying vector8 if he really wants to do
> optimized sums.
>
> Also note the API problem with having a normalize() method here. This
> class RigidTransform was meant to be, well, a _rigid_ transform. If
> you call x.normalize() that means that x wasn't normalized, so it
> wasn't rigid...

Multiplying many orthogonal matrices can lead to loss of orthogonality
anyway, and normalize() is there to prevent it.

Well, repeated quaternion multiplication can also lead to loss of unit
norm, and that's perhaps why there is a normalize method in quaternion
class.

If you have a non-orthogonal rotation, matrix, you are screwed. But
you can just normalize a quaternion and live with a slight amount of
error.
>
>>> For Quaternion, Gael showed us that the operator+ wasn't actually
>>> slow. The limit is between size 6 and 7. So DualQuaternion::operator+
>>> will be slow.
>> That was without vectorization, right? with vectorization, I guess the
>> threshold will be higher.
>
> Indeed. But 1) let's not make code without vectorization slower than
> it has to be, 2) all that is architecture-dependent, depends on how
> many registers we have etc.

Alright then, will try to make it a vector8 and perform operations by
mapping it.
>
>>>
>>> 5) You have some room for optimization, for example in
>>>  inline RigidTransform operator*(const AngleAxisType& aa) const
>>>          {
>>>          RigidTransform temp(aa);
>>>          return (*this)*temp;
>>>          }
>>>  inline RigidTransform operator*(const TranslationType& delta) const
>>>          {
>>>          RigidTransform temp(delta);
>>>          return (*this)*temp;
>>>          }
>>> It's not optimal to construct the temporary and then multiply, as a
>>> simplification occurs if you do both at once.
>> I thought that the compiler will be smart enough to do it, but, will
>> make that change too.
>
> I'd be very surprised if it did, because it would take the compiler
> quite some algebra knowledge to understand that 1,0,0,0 is he unit
> quaternion and that multplying by it is a NOP.

So you think an (*this) * RigidTransform(delta) would be faster? If
so, I'll do it.
>
>>> 6) You also have operator*(Scalar). Same remarks as for operator+, you
>>> said that a scaling wasn't a rigid transformation....? etc.
>>
>> That's why normalize() is provided.
>
> ok, same comments as above (also the same performance issue with
> returning by value)
> If this is only used in nlerp(), let's rather provide nlerp().
>
>> You can call them the primary and the dual part if you want. I just
>> used array borrowing from the complex number class suggestion, to
>> allow certain optimizations.
>
> OK, the current code is fine! I just wanted to know.
>
> Benoit
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay