Re: [eigen] Transform products
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] Transform products
• From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
• Date: Thu, 19 Feb 2009 23:28:25 +0100
• Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KzX1WhwzGa288ey2Nyf9hsGt5mH7ZeWL14jD0kCE5CACnKVqfi1KxK35VFp1uLCM8G HueVRd37W2iluFMbcYsufGc6KeTRdXl4rYv8Fe0CEdZWV75WEBoCovP+ZdY3MmWDnn7c V7Bcs6SuNgYaBN6KVnpm5t+IKhIIM5fmb9nOg=

```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
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

```

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/