Re: [eigen] about Transform API

["Schleimer, Ben" <bensch128@xxxxxxxxx>]

Sounds good to me.




--- On Wed, 8/27/08, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

> From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
> Subject: [eigen] about Transform API
> To: eigen@xxxxxxxxxxxxxxxxxxx
> Date: Wednesday, August 27, 2008, 4:47 AM
> Hi list,
> 
> if we still agree that Eigen should be as close as possible
> to what people
> would write on a piece of paper, then I think Transform is
> poorly designed.
> 
> For instance if you want to concatenate a scale S to a
> transformation T you
> would write:
> 
> paper:  T' = T * S
> or
> paper:  T' =  S * T
> 
> while in Eigen we currently have to write:
> 
> eigen:   T = T.scale(Vector3f(sx,sy,sz));
> or
> eigen:   T = T.prescale(Vector3f(sx,sy,sz));
> 
> What about doing something similar to what I did with
> rotations and
> overloading the correct *= and * operators such that you
> could write:
> 
> eigen:   T = T * Scale3f(sx,sy,sz);
> eigen:   T *= Scale3f(sx,sy,sz);
> or
> eigen:   T = Scale3f(sx,sy,sz) * T;
> 
> then if you want to express:
> 
> paper: T = S * R * L;
> 
> (where L is a translation)
> you could write:
> 
> eigen:  T = Scale3f(..) * RotationType(....) *
> Translation3f(...);
> 
> (with RotationType in {Quaternion, Matrix, AngleAxis,
> Rotation2D } )
> 
> instead of the current:
> 
> eigen:  T.setIdentity();
> eigen:  T.scale(...);
> eigen:  T.rotate(...);
> eigen:  T.translate(...);
> 
> ok, actually the rotate, scale and translate methods return
> a reference to
> T, so currently you can still write:
> 
> eigen:  T.setIdentity();
> eigen:  T.scale(...).rotate(...).translate(...);
> 
> that is not too bad in that case, but think about "T =
> R1 * L * T * R2"
> which involves "pre*" versions of the methods:
> 
> eigen:  T.pretranslate(L).prerotate(R1).rotate(R2);
> 
> IMHO it's quite confusing because it does not give you
> the idea of the
> transformation order: "R1 * L * T * R2".
> 
> From a practical point of view we alrealy have all the
> RotationType, and we
> only need to overload the operators as well as to define
> two wrapper classes
> Scale and Translate. I'm only a bit scared about a
> amount of combinations to
> handle... though all products involving two different
> transformation types
> will generate a Transform, so that's certainely doable.
> 
> Also, perhaps we can keep both API ?
> 
> that's all folk, what do you think ?
> 
> gael.