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

[ Thread Index | Date Index | More Archives ]

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
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay

Rohit Garg

Senior Undergraduate
Department of Physics
Indian Institute of Technology

Mail converted by MHonArc 2.6.19+