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

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Thu, Sep 17, 2009 at 9:56 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/17 Rohit Garg <rpg.314@xxxxxxxxx>:
>> What do others here think about this. Is the API, the unit tests etc.
>> good enough for inclusion in eigen?
>
> OK, indeed RigidTransform.h looks good, but:
>
> 1) please indent only with spaces, not tabs

Yeah, will run it thru indent. :)
>
> 2) absolutely need the standard comment at the top with your copyright
> and the licensing blabla

I know, this is just a base for testing and it is in the form so that
I can use independent of it''s use in eigen.
>
> 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.
>
> 4) You implement operator+ returning by value. That raises 3 questions.
> a) The sum of two rigid transformations isn't rigid anymore, so if you
> keep the name RigidTransform, you can't have an operator+.

So I'll have to call it dualQuaternions, huh? OK.
> 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.

> c) we need to adopt a uniform policy, either we have such operator+
> returning by value in both DualQuaternion and Quaternion, or in
> neither.
But....., it is needed. :|

> 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.
>
> 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.
>
> 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.
>
> ***
>
> Here's  a little idea to make it more easy for the user to do his own
> operations like sum.
> Currently you have two member quaternions so it's not easy for the
> user, e.g. if he wants an optimized sum he must do:
> dualquat.quat[0].coeffs() + dualquat.quat[0].coeffs()
> dualquat.quat[1].coeffs() + dualquat.quat[1].coeffs()
> etc...
>
> Instead you could have only one data member, that would be a vector
> m_coeffs of size 8. You would have a method coeffs() returning a
> reference to it. So the user could do, just like with quaternions,
> dualquat.coeffs() + dualquat.coeffs()
>
> Now how do we address the individual quaternions ? You would have
> member methods quat0() and quat1() returning quaternion references
> obtained with the reinterpret_cast trick.
>
> QuatType &quat0()
> {
>  return *reinterpret_cast<QuatType*>(&m_coeffs);
> }
>
> QuatType &quat1()
> {
>  return *(reinterpret_cast<QuatType*>(&m_coeffs) + 1);
> }
>
> By the way, are there more human friendly names for quat0 and quat1 ?
> Or perhaps they really don't have any simple geometric interpretation?
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.
>
> Benoit
>
>
>



-- 
Rohit Garg

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

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay