Re: [eigen] Do we need geometry refactoring?

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


My opinions,

On Thu, Jul 29, 2010 at 12:56 PM, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> wrote:
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.

Makes sense


2) Unifying member access.

Yes!
 

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?

This all sounds pretty reasonable to me.

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


I haven't looked into the geometry module for a while, and I see that some things have been changing (dev branch). I have a couple of quick questions regarding the Transform class:

- The introduction of the Mode template parameter looks promising, but it does not (yet) seem to be fully in use. For example, the inverse method does not take much advantage of it, and still uses the hint TransformTraits parameter. Will the hint parameter be preserved once the Mode template parameter is better supported?.

- For Mode=Isometry (which does not seem to be documented yet) the transformation should be stored as a (Dim)x(Dim+1) matrix, as in the AffineCompact case, right?.

Cheers,

Adolfo

--
Adolfo Rodríguez Tsouroukdissian, Ph. D.

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden contener información privilegiada y/o confidencial que está dirigida exclusivamente a su destinatario. Si usted recibe este mensaje y no es el destinatario indicado, o el empleado encargado de su entrega a dicha persona, por favor, notifíquelo inmediatamente y remita el mensaje original a la dirección de correo electrónico indicada. Cualquier copia, uso o distribución no autorizados de esta comunicación queda estrictamente prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain confidential information which is privileged and intended only for the individual or entity to whom they are addressed.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this e-mail and/or accompanying document(s) is strictly prohibited.  If you have received this e-mail in error, please immediately notify the sender at the above e-mail address.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/