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.