|Re: [eigen] about Transform API|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
On Wednesday 27 August 2008 17:32:52 Gael Guennebaud wrote:
> in my imagination, Scale and Translation would be new types with
> appropriate operator *... Internally they would store a Vector.
OK for this.
In my opinion, Translation and Scaling (please call it Scaling not Scale...)
should only be helper classes for constructing Transforms. No need for
Translation::operator*(vector) as that is just vector addition. No need for
Scaling::operator*(Vector) either. Above all, no need to allow vector
arithmetic in these classes, i.e. no need for
Translation::operator+(anything). Thomas: that is the main difference with
Point, which would have had to have the whole vector arithmetic API.
The fact that (quoting your first mail) "though all products involving two
different transformation types will generate a Transform" will cause
inefficiency when making a Transform with all 3 kinds of transformations; but
in practice I doubt that affects many people because
a) in most cases there is only translation+rotation, no scaling
b) if the user puts scaling last, it gets optimized as a diagonalproduct.
All in all, I think that's a good move and is consistent with what you've
already done for rotation.
Let's keep the rotate()/scale()/translate() methods because this is what
OpenGL people expect first. Then let's also keep the pre... methods too.
I wonder about the shear() methods. Any use case? I know Qt has them but
that's not reason enough :)