Re: [eigen] Transform products |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Transform products*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 19 Feb 2009 23:28:25 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=EqBtzv6zDn0IXbGgr78ADO0qLdsoENUTiNUDCxZlQco=; b=vcMXLao44SlfZkffqoO+NNsYkfCSIEIvppVmBi4UUxx5FRL8JAtwdEKVt1uUPuzLID HdxXF1mNFmt3+MwIM0CBimqz39JY48lIBWYk7tHmMAXx06Jb8ENkEs89t97y0ei0gP90 zWm/Tzmf3MhUemjMb7zG+Mrw46tsmSuDdQtY0=*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 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

**Follow-Ups**:**Re: [eigen] Transform products***From:*Gael Guennebaud

**References**:**[eigen] Transform products***From:*Gael Guennebaud

**Re: [eigen] Transform products***From:*Benoit Jacob

**Re: [eigen] Transform products***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Transform products** - Next by Date:
**Re: [eigen] ASCII quick reference for Eigen2** - Previous by thread:
**Re: [eigen] Transform products** - Next by thread:
**Re: [eigen] Transform products**

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