Re: [eigen] Do we need geometry refactoring?

[ Thread Index | Date Index | More Archives ]

2010/7/29 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Thu, Jul 29, 2010 at 2:45 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> Translation::translation()
>>>> That may sound redundant, but it would be following what we do in
>>>> transform.
>> I see... ok for the consistency reason, but it's of course
>> incomfortable to have it differ from a constructor only by letter case
>> (t vs T)... perhaps we can have both.
> We could rename translation in Transform. The whole thing originated
> from code in which I had
> Isometry3f R( Matrix4f::Identity() );
> Isometry3f T( Matrix4f::Identity() );
> I then decided to change the type of T to Translation3f - because it
> was simply a translation. And then I needed to change a lot of things.
>>>> 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.
>> Ouch...! What would possibly be the use case for that? Think of it this way:
> Well, after reading it again, I am not exactly sure what I was thinking here. :)
> Maybe I thought it were ok because this works too
> Isometry3f o( Matrix4f::Random() );
> and it is pretty much the same "Ouchness" level.

I see what you mean, sure. The reason is that since an Isometry is
stored as a dense matrix, it has to allow construction from arbitrary
matrices and we have got to leave it up to the user's responsibility
to pass a suitable matrix.

Translation is different in that it doesn't use that kind of dense storage.

> Again, regarding the initialization. Maybe we should add a static
> method Identity() to the transforms.



> - Hauke

Mail converted by MHonArc 2.6.19+