| Re: [eigen] Rigid Transformations in eigen: discussion thread |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Rigid Transformations in eigen: discussion thread
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 17 Sep 2009 13:42:11 -0400
- 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=e4J+psaPJGykbpPHy9pOV5bI0NL1GbWISRz4WYrMal0=; b=CTOSN+3pBhB1Su2OVq41dLume2DfqYvS052h4HjotmpJ7LdDPThAn5ChIgZil6ngBw zy2olOOK3h767UN//c+giOvwHrbtGbf/bu6VIpnT4sWon8MJuJIUW8lm6Gl/ueR++/hV C5Pq82HQw5u6tts4i/fxqQcxhnPq7sr66z4J4=
- 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=FgtoCIzLpESm6F95WPvBf4BGaDj1bgmiuSCll0ZcOapEl/xOBDHIcdPW1EDWDMyrMm exoQJnq15XYaFVylA5xcY14LfoTv6xVO3pSlw6FSSGpER+lEBmO9EQYS8tdTgcvfm3UC 2cyo7/gnR+89vW5+Bmizv/1m5gXAMXch77mYE=
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.
>> 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.
> 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.
Perhaps that can wait until you have extensive unit tests, so as to
avoid introducing a bug here.
Benoit