Re: [eigen] Do we need geometry refactoring? |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Do we need geometry refactoring?*From*: Adolfo Rodríguez Tsouroukdissian <adolfo.rodriguez@xxxxxxxxxxxxxxxx>*Date*: Thu, 29 Jul 2010 14:05:07 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0rCG9E9Xe/Q8WOXqpmPo26ccH1smBxH6ciW6ZEtKOcY=; b=ONSOeejojwAVhF1REhX3Cc8Gw9OnMCZknNdcjKnx0wVifcFmOoxxBl+NueGpxxW92s S6EdFgkaQGAgsz+NL6RfL8hVl2GmmKFneOTTStfxZ7uP2oN/a1DIwzFHYNiUV4uMuNJO q1fh6DHRpOWDYfmMcLkLtgoLMsOIdEV49Ldpc=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=NJwY0bePcSrrCs+FStPvw8CrKB0O4J5X6Ic+0WMSWAtkkTfv01yangJEOoGW4dQHXO /+rdfC70rk9302ugX/70EWkdwKh932wt9z+wo2JwdvyAotE1lZsyqhvMiGpUPH5YEv/K e7jC1za54EoITalB7CLDqQH2RL7MFjPyZ2GOU=

My opinions,

On Thu, Jul 29, 2010 at 12:56 PM, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> wrote:

Makes sense

Yes!

This all sounds pretty reasonable to me.

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

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

**Follow-Ups**:**Re: [eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Re: [eigen] Do we need geometry refactoring?***From:*Benoit Jacob

**References**:**[eigen] Do we need geometry refactoring?***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Do we need geometry refactoring?** - Next by Date:
**Re: [eigen] Parallelizable operations** - Previous by thread:
**[eigen] Do we need geometry refactoring?** - Next by thread:
**Re: [eigen] Do we need geometry refactoring?**

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