[eigen] Do we need geometry refactoring?

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

Hi,

I was once again working a bit with the geometry module and stumbled
over a few tiny issues.

1) I discussed this before with Gael but did not commit yet so I am
repeating it here. We think it makes sense to default transformation
modes to Projective. This is more generic and safer.

2) Unifying member access.

We have several classes that behave like matrix transformations in the
sense that they define the required products in order to mimic a
matrix. The core class is Transform and transforms allows the user to
access the underlying matrix in several ways

Transform::matrix() returns a homogeneous representation of the transform
Transform::linear() returns the upper left Dim by Dim component of the matrix
Transform::translation() returns the translation, upper right Dim by 1

But what about other classes, how about e.g. Translation? Translation
allows to access the data via a single function called
Translation::vector() - this is not very intuitive. And I would prefer
another function

Translation::translation()

That may sound redundant, but it would be following what we do in
transform. We could even offer Translation::matrix() and return a
read-only identity. This function is one step towards being able to
interchange types as Isometry3f and Translation3f (in case the
isometry were just a translation).

Ok, the question is actually whether we want Translation, Quaternion,
etc. behave like Transformations? Should we allow the same
initialization as well, so would it make sense to allow initialization
of a translation from a (Dim+1) by (Dim+1) matrix?

3) This is more like a tiny question. Why are we setting the
projective part of the matrix to 0 ... 0 1 in the inverse method? I
think it is absolutely useless since it should already be like that...

- Hauke