Re: [eigen] Do we need geometry refactoring?

[ Thread Index | Date Index | More Archives ]

> Why? I think I start to understand your confusion. Do you consider a
> "Transform" to be affine and or isometric?
something more general: a (N+1)x(N+1) linear application as I
understand that is what the Transform class can be.
In my opinion, the main interesting part of this kind of API is to
allow easy definition of rotations and to mix them with other kind of

> In our case the class for a general non-linear transformations is
linear transformation in (N+1)x(N+1) space, or do I miss some
restriction on what a transform can be ?
> called Transform and thus (IMHO), Transform3f should be as general
> since the name is so close to the class name
In this case I vote for Transform3x == Affine3w != Transform<X,3>
(default parameter to Projective)
which is a slightly different from what you proposed before
because otherwise I think that people will use Matrix4x instead of Transform

> This works now out of the box because unless you don't specify
> (Affine3f = Transform<float,3,Affine>) it is assumed to be fully
> projective. Your compilation will even break in case you use fixed
> size types.
that is very nice!
>> Perhaps an alternative would be that Transform3x is Affine but not the
>> default parameter of the class Transform ?
> As I said. I don't like it because Transform3x implies a general
> homogeneous 3D transformation
In my mind there was no such concept, the closest concept I come with
is the concept of a 4D linear transformation, so I think it is
confusing to use Transform3x for that.
But if a typedef is really needed for such a thing ... perhaps it is
better to pick something else.

- Manuel

Mail converted by MHonArc 2.6.19+