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*: Rohit Garg <rpg.314@xxxxxxxxx>*Date*: Thu, 17 Sep 2009 23:04:31 +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 :content-transfer-encoding; bh=fahzAPhOLcNljxgHCJgtMbMbUqKk0ec+BWfyctsoGes=; b=A+Q1AktS7FWOdu/calezVIPWmI3gKpTxKe6WobY3lFbOJsW/Y1oVxJk99DcYFqVzy7 kqhg7+BT0fJZ6A5Z3ceH+LCwdI37/uBaK8HrwFfnBufDeYwKZM38SIXdhyAY6mEiHMf3 IUYcbmU6aZd8ITMR1fLFvk09Vr/ITuFYo/rHc=*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:content-transfer-encoding; b=jNuj9fkFR6tX6jJNMkmVyryrBqaCLek5p6IiriHsVaP7wiXiml3zx76qL6xy/YecHI 9C2H1WofUTx1APfJHMpfO6jOKF28uctJg0mUY1EKzxaHLf/hNAHh7upMLieRrHyorLep V1xVyRkkBhqsZz487frOo4hyxmRvhdoN8tZJg=

> I'm not sure that we want to abstract it and 'hide' the quaternion aspect.. > 1) this isn't what we have done with the Quaternion class > 2) being able to access the underlying quaternions may be useful if > the user was already using quaternions in his framework Good point. > 3) calling it DualQuaternion also makes room for other rigid > transformation classes, should any appear. Like the Quaternion classes > leaves room for there to be other rotation classes. Fair enough. > >>> b) is there any use case, in 3D graphics, to add two dualquaternions? >> >> Google for the paper, "Dual Quaternions for Rigid Transformation >> Blending". The transformation blending is implemented by linearly >> blending dual quats and then normalizing. BTW, (linear >> interpolation+normalization) is also the cheaper cousin of slerp for >> quaternions, sometimes called nlerp. > > OK, that's sort of what I suspected: the only obvious way that adding > (dual-)quaternions and multiplying them by scalars would make sense in > practice. > > 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? > > Meanwhile we do a trick as i discussed in previous emails to allow the > user to easily address the underlying vector8 if he really wants to do > optimized sums. > > 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. 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. But you can just normalize a quaternion and live with a slight amount of error. > >>> For Quaternion, Gael showed us that the operator+ wasn't actually >>> slow. The limit is between size 6 and 7. So DualQuaternion::operator+ >>> will be slow. >> That was without vectorization, right? with vectorization, I guess the >> threshold will be higher. > > Indeed. But 1) let's not make code without vectorization slower than > it has to be, 2) all that is architecture-dependent, depends on how > many registers we have etc. Alright then, will try to make it a vector8 and perform operations by mapping it. > >>> >>> 5) You have some room for optimization, for example in >>> inline RigidTransform operator*(const AngleAxisType& aa) const >>> { >>> RigidTransform temp(aa); >>> return (*this)*temp; >>> } >>> inline RigidTransform operator*(const TranslationType& delta) const >>> { >>> RigidTransform temp(delta); >>> return (*this)*temp; >>> } >>> It's not optimal to construct the temporary and then multiply, as a >>> simplification occurs if you do both at once. >> I thought that the compiler will be smart enough to do it, but, will >> make that change too. > > 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. > >>> 6) You also have operator*(Scalar). Same remarks as for operator+, you >>> said that a scaling wasn't a rigid transformation....? etc. >> >> That's why normalize() is provided. > > ok, same comments as above (also the same performance issue with > returning by value) > If this is only used in nlerp(), let's rather provide nlerp(). > >> You can call them the primary and the dual part if you want. I just >> used array borrowing from the complex number class suggestion, to >> allow certain optimizations. > > OK, the current code is fine! I just wanted to know. > > Benoit > > > -- Rohit Garg http://rpg-314.blogspot.com/ Senior Undergraduate Department of Physics Indian Institute of Technology Bombay

**Follow-Ups**:**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**References**:**[eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Adolfo Rodríguez

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Adolfo Rodríguez

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Rohit Garg

**Re: [eigen] Rigid Transformations in eigen: discussion thread***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - Next by Date:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - Previous by thread:
**Re: [eigen] Rigid Transformations in eigen: discussion thread** - Next by thread:
**Re: [eigen] Rigid Transformations in eigen: discussion thread**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |