Re: [eigen] Do we need geometry refactoring?

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

2010/7/29 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> I forgot to comment on this before...
>
> On Thu, Jul 29, 2010 at 2:45 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> Ok, the question is actually whether we want Translation, Quaternion,
>>>> etc. behave like Transformations?
>>
>> Translation and Quaternion are different beasts here.
>>
>> The reason for Transform to exist is to represent non-linear (i.e.
>> affine/projective) transformations.
>
> Isn't it only the projective part that makes the whole thing
> non-linear? It that were true, you have like 2/3rd of the cases being
> linear ones.

Linear (in this context) means f(ax+by) = af(x)+bf(y). (Equivalently
it means "a matrix transformation without using any homogeneous
coords".) That entails in particular f(0)=0. So translations are
nonlinear, so isometries and general affine transforms are nonlinear ,
unless of course their translation component is 0.

>
>> Translation is indeed a special case of that. But a Quaternion of norm
>> 1 represents a rotation which is linear, so there is no reason to
>> bother about Transform here; instead we unify Quaternion with other
>> rotations in RotationBase and we take care once and for all of the
>> interplay of rotations with general Transformations.
>
> I was primarily thinking about adding methods
>
> ::matrix() (returns a homogenous matrix)
> ::linear() (returns a pure matrix)
> ::translation (same as ::matrix(), read only expression)

What do you mean when you say that ::translation() is the same as ::matrix() ?

I agree about having these method in all geometry classes for
consistency although I wonder about their usefulness in the cases
where they would be trivial (i.e. linear() in Translation).

Benoit

>
> We already have toRotationMatrix() and again it was the different
> naming that confused me.
>
> - Hauke
>
>
>