|Re: [eigen] Rigid Transformations in eigen: discussion thread|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Rigid Transformations in eigen: discussion thread
- From: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Thu, 17 Sep 2009 23:25:58 +0530
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=gEIoybM4dBDdF+TaQP7vjOMD4OZ224+ieV/xbqx6z6Y=; b=d0fEVKvLL34Lhm6GgpL9zKxN+FS8Si38lnXy5Sjg4pRYk629YrZbX7zqeOWI95xyum HXqbMOfG7GHcmKf/0tcsyiKt4tqs8YuAFx3BNQ2kamMvymhFg7hgYJTY1a5+xxkD88ED 4m1ePi0WZdl8iTiln2b0dXzOOqqJwFb81kiAs=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=knh+z8oplPTYTizCOGwlBr3wljGAg9a+BOYNWfKUoNx1+wD0bTwpJeWgWvwLUKv/2d 5AJVWkyA1YNBBfYYHXAF86GfqUJfM/XbFMH4dbLFixtamSm69xTdLKKzeMOcP/etb/Cs KSj8nPJyAwhbXIAxrUMQ4nJQZ4m0/TfRy7qgc=
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
>> 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
>> you can just normalize a quaternion and live with a slight amount of
> 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.
> 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?
Department of Physics
Indian Institute of Technology