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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/9/17 Rohit Garg <rpg.314@xxxxxxxxx>:
>> 3) about the name of the class, why not DualQuaternion? We already
>> have a Quaternion class that behaves like a transform, so it seems
>> that you're doign the analogue here. Of course, my hidden motivation
>> for avoiding the name RigidTransform is that i still think that it
>> should be called Isometry ;) basically there's a debate between
>> RigidTransform and Isometry while at least there is no debate about
>> DualQuaternion.
>
> You can call it isometry if you want. Dual quaternion is just an
> implementation detail, so I wanted it abstracted. ATM, the quaternoin
> components aren't exposed, so it made sense to not call it the
> dualQuaternion. But names are a minor point. Though I prefer
> isometry/rigidtransform over dualQuaternion.

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

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

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

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

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

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