Re: [eigen] geometry module

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

2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>:
> As I mentioned in the previous email, I've been having a gander at the
> new geometry module. Not sure who's putting it together, but wondering
> if they'd mind me picking their brain a bit.
>


First of all, the Transform class is for transformations represented
by matrices i.e. homographies. It's not a statement that no other
representation is interesting, it's just what this class is doing.
Other representations may be added as separate classes.

> We're using transforms for robotics, so strictly rotations and
> translations. A 2D setup might only need 3 variables, angle + x-trans
> + y-trans.

The problem with representing a transformation using an angle, is that
subsequent computations are relatively slow as one needs to compute
cosines and sines. If however you're OK with representing the angle as
a (cosine, sine) pair, then Rotation2D is doing that. If you want a
class that combines a Rotation2D with a translation vector, which
could be called Isometry2D, indeed we don't currently have that.

> A 3D setup could most efficiently run with quaternion + 3
> element vector for translation.

Here, "most efficiently" depends on what you're doing. If you want to
apply this transformation to a vector, it's going to be faster if you
have a matrix representation of your transform, as the Transform class
does. This is one of the most performance-critical use cases...

That said, either what you propose (quaternion+vector) or a "dual
quaternion" class as has been discussed previously on this list, would
be interesting. We just happen not to have that yet.

I think that given sufficiently explicit names, different classes can
coexist. The name Transform may not be very explicit though, but the
matrix approach is the only one to be generally applicable (any size,
no assumption on the transformation...) so that warrants a relatively
generic name.

> I see that some optimisations are
> being made to the transform class - e.g. CompactAffine. There is also
> Isometry - how exactly does this differ from the Affine types,

Isometry means Affine from the point of view of storage. The only
difference is that if you use Isometry, then you guarantee that the
transformation is actually an isometry, i.e. an orthogonal
transformation + translation vector. This allows Eigen to generate
faster code for certain operations like inverse().

By the way --- others: shouldn't Isometry be CompactAffine instead of
Affine? Or should there be a CompactIsometry, etc.

> and
> was/is there any design thoughts behind more optimised
> storage/calculation processes (i.e. quaternion instead of 3d rotation
> matrix, angle value instead of 2d rotation matrix)?

as said above:
 - for 3d isometries, quat+vector or quat+quat have been discussed
previously, would be a welcome addition
 - for 2d isometries, angle is inefficient, combining
Rotation2D+vector is the right approach.

Benoit

>
> Many thanks,
> Daniel Stonier.
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>
>
>