Re: [eigen] Rigid transformations in eigen: use of dual quaternions

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Sat, Sep 12, 2009 at 10:10 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/12 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 2009/9/12 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>> 2009/9/12 Rohit Garg <rpg.314@xxxxxxxxx>:
>>>>>> For what-are-dual-quaternions, look at the paper here
>>>>>>
>>>>>> http://isg.cs.tcd.ie/projects/DualQuaternions/
>>>>>
>>>>> Hm that page wasn't very explicit, but I found this:
>>>>>
>>>>> http://en.wikipedia.org/wiki/Dual_quaternion
>>>>
>>>> Must have been taken down. Paper attached.
>>>
>>> woops, please don't attach heavy files to mails on this list! I'll
>>> edit the wiki to mention that.
>>>
>>> the link wasn't down, i had seen the file, still i found it less
>>> explicit than the wikipedia page as far as the definition of dual
>>> quaternions was concerned.
>>>
>>>>>> All in all, dual quaternions are to rigid transformations what
>>>>>> quaternions are to 3D rotations. The biggest advantage is to treat
>>>>>> rotation and translation in a unified framework.
>>>>>
>>>>> If it were just that, we have the Transform class. But I understand
>>>>> that the dual quaternion representation allows for that interesting
>>>>> slerp-like interpolation, i can believe it's useful, and dual
>>>>> quaternions have a wikipedia page mentioning applications to 3D
>>>>> graphics, so, no need to convince me any more than that. I'd say, go
>>>>> for it!
>>>>
>>>> The advantages are cheaper to store, cheaper to compose, more stable
>>>> and interpolation. In that sense, they correspond to the advantages of
>>>> quaternions over matrices.
>>>
>>> ok, understood.
>>>
>>>>
>>>> Question: can you map a piece of memory as a Quaternion<datatype>
>>>> (with vectorization)? Like the question I raised earlier today where a
>>>> vec4i wasn't vectorized.
>>>
>>> Hm, no you currently can't. But Eigen can be modified so that you
>>> could. If you want to give it a try, look at DiagonalMatrix.h, how
>>> DiagonalMatrix is storing its own coeffs like Quaternion does while
>>> DiagonalWrapper wraps an existing MatrixBase (which could be a
>>> Map...).
>>
>> Ah, I'm stupid. Since that's only for some internal code that you have
>> to write only once, what do you think of just doing a
>> reinterpret_cast? That gives the same result with much less hassle!
>>
>> Like this
>>
>> float data[4];
>>
>> reinterpret_cast<Quaternionf*>(data)->slerp(....);
>>
>> Benoit
>
> Ah, one precision: here it's crucial that data is 128 bit aligned!
>
> We don't have any way to map a non-128bit-aligned buffer as a quaternion.
>
> Benoit
>
>
>

hi,

I don't have much right now to address all the issues raised in that
thread, but at least:

- here we are speaking about 4 scalars only, and so there is no
advantage in using expression template (wrt performance). So here
returning by value is fine.

- I'm not in favor in adding operator+ and scalar multiple to the
Quaternion class for the same reason than Benoit.

- Quaternion::operator=(MatrixBase<>) is to convert a rotation matrix
to a quaternion, so quat = q1.coeffs() + q2.coeffs(); won't work.

- I don't really llike the idea of adding operator() as shortcut for
coeffs(), because, e.g.,  q1() looks very weird.Currently, the only
use case is to write the DualQuaternion class, and here it is
perfectly fine to use .coeffs().


I'm looking forward the DualQuaternion class, whatever its real name will be ;)


gael