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

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Thu, Sep 17, 2009 at 11:12 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/9/17 Rohit Garg <rpg.314@xxxxxxxxx>:
>>> Then I would much rather have a specialized method nlerp() for that.
>>
>> With a specialized nlerp() you can't go general blending, which is
>> needed while performing character skinning.
>>
>> IE, operations like (w1*Q1+w2*Q2.....+wN*QN).normalize(), what about them?
>
> Good point, I need to think about that. Didn't know that that was used
> in practice.
>
> The operator+ and * as you proposed, again, will give poor performance
> in non-vectorized mode (because 8 scalars is too much). Ideally, we'd
> find a solution that's efficient also in non vectorized mode.
And here's where a vector8 will help, I assume using it will enable
expression templates. Right?
>
>>> Also note the API problem with having a normalize() method here. This
>>> class RigidTransform was meant to be, well, a _rigid_ transform. If
>>> you call x.normalize() that means that x wasn't normalized, so it
>>> wasn't rigid...
>>
>> Multiplying many orthogonal matrices can lead to loss of orthogonality
>> anyway, and normalize() is there to prevent it.
>
> Good point, I didn't think about that.
>
>>
>> Well, repeated quaternion multiplication can also lead to loss of unit
>> norm, and that's perhaps why there is a normalize method in quaternion
>> class.
>>
>> If you have a non-orthogonal rotation, matrix, you are screwed.
>
> No, you can get away with a gram-schmidt, but I agree that it is much
> more costly than normalizing a quaternion.

The classic Grahm schmidt has a very poor numerical stability. It can
be modified to run in a stable manner, but there is ~2x operation
penalty.
>
>> But
>> you can just normalize a quaternion and live with a slight amount of
>> error.
>
> I see the point, now.
>
>>> I'd be very surprised if it did, because it would take the compiler
>>> quite some algebra knowledge to understand that 1,0,0,0 is he unit
>>> quaternion and that multplying by it is a NOP.
>>
>> So you think an (*this) * RigidTransform(delta) would be faster? If
>> so, I'll do it.
>
> No, that's not what I was suggesting. I was suggesting that you work
> out the simplified formulas on pen and paper, and then implement that.

I see.
>
> Perhaps that can wait until you have extensive unit tests, so as to
> avoid introducing a bug here.

Another good point. What do you think of the current unit tests?


-- 
Rohit Garg

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

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay