|Re: [eigen] Do we need geometry refactoring?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Do we need geometry refactoring?
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Tue, 17 Aug 2010 22:15:36 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=UbbBfDUhrys0R9UZ+8Awvx6PDLKJo3j1TPg/jXGx9Qg=; b=EdfLW3bgIidPeAAVVZ3uumygmHBj57fPm12Rr+X5mZXm9FbglT4D98uvvbpe9CRPEK 7itfMunmnfUG62PD56ZU6B/rhJl2qKHWmhatBl1Ww+dkFU0Z4fYQ+0PUU1GEU+7O9zFD vIlArAOurd/QgliJShDFjhuH0aPt4DsUYT4NE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=JwCY6BqqPfK5yY7Njwre6z1vH6WrYN7xkEN40f5LLZ2k9KrdkgC44opgpjfNaBJjhU k3zxs7vQTJNPpwZG9NT8Z3jiG99QZIV3fzzISIuWbrBjDiYmpAbQcGzc6ZYE+RG+re3c IeJQ+htIcz8kU4f8AwmVUoL9oFgCDxVK4l04o=
I looked into the remaining transformations and there seem to be some
bugs hidden which are not exposed by our unit tests. Maybe some of
them or only because of my changes.
First, on thing I recognized. You consider any fixed size (Dim)x(Dim)
or (Dim+1)x(Dim+1) matrix as a linear and generic transformation
respectively. Therefore, we have the following special product paths
1) T * linear matrix => T
2) T * generic matrix => Projective
Both are violated in case the RHS matrices are not invertible.
Rule 1) is on top violated, in case the "linear" matrix is not
orthogonal and applied to an Isometry.
For these paths, my suggestion is to prohibit case 1) completely. I
think the functionality is well covered by
T.linear() *= linear matrix
For case 2), I would choose to simply return a matrix. This is
mathematically more sane and in case your are dead sure, what you are
doing, you can still do
T * Projective(generic matrix)
T * Affine(generic matrix)
This is even better because it will not necessarily end up with a
projective transformation. It is also more explicit (the ctors are
explicit) and leaves no option for interpretations as to what is
The next issue - and this maybe newly introduced by me - is that currently
Transform<Scalar,Dim,Projective> * Matrix<Scalar,Dim,Dynamic>
compiles. The chosen implementation path is wrong because it assumes
Affine or Isometric times set of points and even if we agreed upon
extending the RHS matrix by 1s as their homogeneous coordinates, we
were suddenly required to return something homogeneous.
Let's quickly take a look at what kind of point transformations we
currently allow for Affine and Isometry:
a) T * Matrix<Scalar,Dim,Dynamic>
b) T * Matrix<Scalar,Dim,1>
c) T * Matrix<Scalar,Dim+1,1>
On top, we allow for Projective
d) T * Matrix<Scalar,Dim+1,Dynamic>
I would propose to allow d) for Affine and Isometry too. It is
mathematically perfectly valid and would simply leave the homogeneous
Currently, the only issue is that we allow
T * Matrix<Scalar,Dim,Dim> --> T
T * Matrix<Scalar,Dim+1,Dim+1> --> Projective
as discussed above. In case we do what I proposed, the ambiguity were
resolved and we could allow d) for all transformations.
Here is the summary of allowed transforms as I suggest to offer them -
the asterisk is a wildcard for anything.
// this is all for projective
Matrix<Scalar,Dim+1,*> = Transform<Scalar,Dim,Projective> *
// these for Affine, AffineCompact and Isometry
Matrix<Scalar,Dim+1,*> = Transform<Scalar,Dim,Affine> * Matrix<Scalar,Dim+1,*>
Matrix<Scalar,Dim,*> = Transform<Scalar,Dim,Affine> * Matrix<Scalar,Dim,*>
What do you say? The changes are easy and they will reduce code and
template instantiations, make our code more safe and more easy to
understand -- for the user and devloper.