On Thu, Jul 29, 2010 at 12:56 PM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
Hi,
I was once again working a bit with the geometry module and stumbled
over a few tiny issues.
1) I discussed this before with Gael but did not commit yet so I am
repeating it here. We think it makes sense to default transformation
modes to Projective. This is more generic and safer.
Makes sense
2) Unifying member access.
Yes!
We have several classes that behave like matrix transformations in the
sense that they define the required products in order to mimic a
matrix. The core class is Transform and transforms allows the user to
access the underlying matrix in several ways
Transform::matrix() returns a homogeneous representation of the transform
Transform::linear() returns the upper left Dim by Dim component of the matrix
Transform::translation() returns the translation, upper right Dim by 1
But what about other classes, how about e.g. Translation? Translation
allows to access the data via a single function called
Translation::vector() - this is not very intuitive. And I would prefer
another function
Translation::translation()
That may sound redundant, but it would be following what we do in
transform. We could even offer Translation::matrix() and return a
read-only identity. This function is one step towards being able to
interchange types as Isometry3f and Translation3f (in case the
isometry were just a translation).
Ok, the question is actually whether we want Translation, Quaternion,
etc. behave like Transformations? Should we allow the same
initialization as well, so would it make sense to allow initialization
of a translation from a (Dim+1) by (Dim+1) matrix?
This all sounds pretty reasonable to me.
3) This is more like a tiny question. Why are we setting the
projective part of the matrix to 0 ... 0 1 in the inverse method? I
think it is absolutely useless since it should already be like that...
- Hauke
I haven't looked into the geometry module for a while, and I see that some things have been changing (dev branch). I have a couple of quick questions regarding the Transform class:
- The introduction of the Mode template parameter looks promising, but it does not (yet) seem to be fully in use. For example, the inverse method does not take much advantage of it, and still uses the hint TransformTraits parameter. Will the hint parameter be preserved once the Mode template parameter is better supported?.
- For Mode=Isometry (which does not seem to be documented yet) the transformation should be stored as a (Dim)x(Dim+1) matrix, as in the AffineCompact case, right?.