| 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 14:08:36 -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=XBWVak7PiycofREkQODX9+BreK0pEvs3RXkHldLHsys=; b=GzE2Dinf+8QJ2L8ZX/dP1Z5r8kYEZgcpSQxWo9eKZda50hP+7ikP7YGBFEcI5hLUgm rZ4/2VnUZts215JFY2mhLO4D8vT4Y1iZlDmDYf/9HhJtF/vSv8kyGCZR62o33lGgFUmn gVy+GsefFzQsafp0sd+0ZDZRjl0xpE4nsLDRU=
- 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=tDVvXeipd0sPc7mtD8uHi1oJwZnaDWFrKiB6Hf9uRYy5LxGlYYJv1YnFX2QBzh9hNs +6aRco28VD8j79dvNB5QWHWJ6aApf7ZyZCY8+PJvrpJAi7tAkRkYhIZDnJucwU+Jh1ip 2lm8NEViTcp/G0Jpa/S28iAB6NiJoQ7hA/f/s=
2009/9/17 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?
Yes. So if the user is OK to cope with having to call coeffs(), then
he can do all what he likes, and get optimized code thanks to ET.
> 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.
Not when the matrix was already very close to being orthogonal, as is
the case here if you re-normalize frequently enough. In that case,
Gram-Schmidt is fine. But that is OT, as indeed it's never as good a
solution as quaternions.
>
> Another good point. What do you think of the current unit tests?
sorry, haven't had time to look at it carefully.
i guess the cout's aren't there to stay, for the rest i need to read
it carefully, have to run now...
Benoit