Re: [eigen] Transform products

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

I have to say: I'm puzzled!

at least I agree to add homogeneous normalization functions:
  v.hnormalized();
  data.colwise().hnormalized();
  data.rowwise().hnormalized();
(for the name feel free to suggest something different)

and then a "projective transform" * "set of non homogeneous vectors"
would not perform an automatic normalization, but return homogeneous
vectors. Then it is up to the user to normalize the result.


I'm not fan of the "as homogeneous" expression because it would
require a if inside coeff, but since it might be removed by the
compiler, why not...  I think that's better to make Transform good
enough so that such an expression would not be needed. And by the way,
currently you can do:
VectorType v;
HVectorType hv;
// ... work with v
// then you temporally need an homogeneous vector:
hv << v, 1;
// use hv

that's not more verbose than a call to .asHomogeneous()

About splitting the current Transform into 3 versions... well that
would probably be ideal, but this would significantly increase the
number of product combinations... I still have to think about it.

gael.

On Thu, Feb 19, 2009 at 11:28 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> OK, I needed some time to dive back into that stuff...
> it's true that we want general projective transforms, if only for
> OpenGL projection matrices. And it's true that we want to multiply
> these by vectors and normalize the result. ok, now i remember.
>
> Here's one idea: the user knows, when he declares a matrix, whether
> it's going to be affine or projective. So no need to force him to call
> .affine() everytime, he could just declare that once and for all. In
> other words, these should be separate Transform types (and they should
> be available for storage, not just temporary proxies).
>
> It's up to you whether you prefer to add a template param to Transform
> or to add new classes. I think we actually want 3 cases:
> 1) affine transform stored as a (d+1)x(d+1) matrix (should be still
> called Transform to minimize incompatibility between 2.0 and 2.1, as
> most users of transform only use affine transforms)
> 2) affine transform with optimized storage: d x (d+1) matrix. Or even
> dxd matrix and separate d-vector.  (Allows vectorization in 2d and 4d
> cases).
> 3) projective transform stored as a (d+1)x(d+1) matrix.
>
> I think that even in the projective transform case, transform * [d x
> 1] should still return a [d x 1] normalized vector. If the user wants
> a homogeneous result, he just passes a homogeneous vector so we're in
> the transform * [d+1 x 1] case. I'm OK to have an xpr to append a 1 at
> the end of a vector (no cost in unrolled fixed-size case) so that
> would be zero-overhead,
> transform * vector.homogeneous();
>
> [oh, I see Keir is proposing exactly the same also for matrices, yep
> that sounds like a good idea.]
>
> The idea is we can't please everybody and we're not going to code the
> ultimate projective geometry package. I'm in favor of keeping it
> simple, covering 98% of use cases, try to have consistent and
> predictable behavior. If we add a super clever logic but it ends being
> hard to predict for the user, then it's useless. So i'm not in favor
> of more complicated expressions here.
>
> Cheers,
> Benoit
>
>
>