Re: [eigen] Rigid Transformations in eigen: discussion thread

[Rohit Garg <rpg.314@xxxxxxxxx>]

What do others here think about this. Is the API, the unit tests etc.
good enough for inclusion in eigen?

On Wed, Sep 16, 2009 at 4:06 PM, Rohit Garg <rpg.314@xxxxxxxxx> wrote:
>>> a) This heavily depends on fast quaternion multiplication, I think it
>>> will likely come out somewhat behind in benches.
>>
>> OK, so it would definitely be nice to know how much behind. I haven't peeked
>> into the internals of the Quaternion class, but would this difference be due
>> to the current implementation, or rather inherent to the involved operations
>> and their efficient vectorization?
> Quaternion multiplication is vectorized, and is ~2x faster than it's
> scalar equivalent. I dont know how to speed it up, apart from
> scheduling instructions by hand. Suggestions most welcome. Multiplying
> dual quaternions takes 3 quaternion multiplications and one addition.
>
> Off the top of my head, Matrix4f multiplication takes 28 SSE
> instructions at the minimum. A quaternion multiplication takes 7 and
> addition just one. So theoretically, it may be faster, but modern
> Intel CPU's can dual issue a mul and an add per clock, so by careful
> ordering, it may be possible to do the matrix multiplication in lesser
> (~half) cycles. The only real way to know for sure is to bench it. And
> I dont have time for it now, but I'd be interested in the benchmarks.
>
>>
>>>
>>> b) How does eigen do say, 4D rotations? I thought it did only 2D and
>>> 3D rotations.
>>
>>
>> In the Transform class, a higher-dimensional rotation would be the linear
>> part set to a square nD orthonormal matrix
> But you will have to manage the orthonormal matrix yourselves right? I
> mean is there an angle axis or its equivalent for 4D? Any support for
> composing 4d rotations in eigen?
>
>>> I don't know if rigid transformations make sense for 2D.
>>
>> They do :) , rigid transformations make sense in nD
> That's interesting.
>
>> Sure. The main point is that a specialization for rigid transformations
>> could be very useful. The Transform class already takes isometries into
>> account up to a certain extent (as a hint when computing the inverse), but
>> it would be nice to have a way of creating isometries, and guaranteeing that
>> they stay that way. With the current Transform class, you could for example
>> compose multiple isometries and because of roundoff errors end up with
>> something that is not an isometry, and restoring orthonormality of the
>> linear part is not trivial. For 3D isometries, renormalizing a quaternion is
>> all you need (or similar for dual quaternions). This is why your
>> contribution seems worth exploring :).
>
> The thing is a Transform object could also contain a scaling/shearing
> transformation, which is unacceptable for a rigid transformation. The
> transform class is suitable for opengl transform matrices, but not for
> rigid objects.
>
> The biggest advantage, the raison d'etre of this class, is
> interpolation of rigid transformations, essential in animations.
>
> Cheers,
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay