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

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

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