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

[Rohit Garg <rpg.314@xxxxxxxxx>]

>> 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