Re: [eigen] geometry module...

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

By the way, I wonder a bit about the Translation class. Most of the
time, the user has a vector and wants to apply the translation by that
vector, without any overhead.

Our Translation class doesn't allow that. It stores its own vector...

How to solve that? Perhaps this is the "usual Eigen way" to solve this
kind of problem:
 - introduce TranslationWrapper class that is like Translation except
it wraps an existing expression
 - introduce MatrixBase::asTranslation() returning a
TranslationWrapper, so one could do: some_vector.asTranslation()
 - introduce TranslationBase factoring most of the code between
Translation and TranslationWrapper

Then this has the added benefit that it allows to very easily bring
expression templated to Translation: just let operator+ return a
TranslationWrapper<CwiseBinaryOp<...> >

We already discussed such plans for Quaternions. It's the same here.

The nice thing is: afaics, it doesn't break any API so there's no
emergency. But it would be very welcome... (unless someone
disagrees...)

By the way there's a similar problem in other classes of the Geometry
module. If I have an existing 4x4 matrix and want to "view" it as a
Transform3d, currently Eigen doesn't allow me to do that, right?
That's pretty bad! I may be missing something. Anyway, in that case,
the same approach would work there too...

Benoit


2010/3/19 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> My point is that we must preserve associativity (up to machine precision ;) )
>
>  (Scaling * Translation) * Vector == Scaling * (Translation * Vector)
>
> We would lose that if we let Scaling * Translation return the
> translation by the scaled vector.
>
> Benoit
>
> 2010/3/19 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
>> On Fri, Mar 19, 2010 at 7:44 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> - make UniformScale * Translation return a Translation
>>>
>>> I don't understand that. UniformScale * Translation should return the
>>> composite transformation, that consists in first translating and then
>>> scaling. This is not a translation!
>>
>> Well, maybe the bigger problem is that we do not yet have expressions
>> in the transformation chain. A translation is not even a
>> transformation but it behaves as such since
>>
>> Vector = Translation * Vector
>>
>> is a valid operation - i.e. translations behaves like a transformation
>> matrices. And given
>>
>> Vector = Scaling * Translation * Vector
>>
>> which can be written as
>>
>> Vector = (Scaling * Translation) * Vector = OtherTranslation * Vector
>>
>> I considered returning a translation - in particular since
>>
>> Translation * Vector
>>
>> is way more efficient than
>>
>> ProjectiveTransformation * Vector.
>>
>> Maybe now I managed to maximize confusion but I agree that such a
>> trivial fix is not really a fix and thus I will leave it alone for the
>> moment.
>>
>> - Hauke
>>
>>
>>
>