Re: [eigen] Do we need geometry refactoring?

[ Thread Index | Date Index | More Archives ]

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


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

Mail converted by MHonArc 2.6.19+