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:21:15 -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 :content-transfer-encoding; bh=G9qerA7+ug+VjB+w18DhJkTIwqzpKwKQ4trSmqoUWwY=; b=S4zxOlxyyMAfey1OAd7SWGEqcTjHDigbtQgIfix4Ap83zSe1c5GZtv3gdO1NvtzEyN DIAjURClesyLcQi0+JQVIKjIo4E/64qt/tOg222EspdljHlFNR6pBzpJcZXCuM9nIXNx UED8yisceuuxJx8DfcIJG92+Daaq0QVNkX/X8=*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=gyZL5LNkMC/8ereRLLEAgh8fVdZ/ceWEtH9JoETMiKb8N4d2uo6aAa9my+zGRylLuo KIcytVWmdJoETzmctWpZYy1SDQhwCgQzbahCeSVJ02xaQStbS1yUsUc88nJYuEXt1Uby lhn7UD0XrjR1aXiVEWWvZ+Sl/ac6gh2HuAAK4=

2009/9/17 Rohit Garg <rpg.314@xxxxxxxxx>: >> 3) about the name of the class, why not DualQuaternion? We already >> have a Quaternion class that behaves like a transform, so it seems >> that you're doign the analogue here. Of course, my hidden motivation >> for avoiding the name RigidTransform is that i still think that it >> should be called Isometry ;) basically there's a debate between >> RigidTransform and Isometry while at least there is no debate about >> DualQuaternion. > > You can call it isometry if you want. Dual quaternion is just an > implementation detail, so I wanted it abstracted. ATM, the quaternoin > components aren't exposed, so it made sense to not call it the > dualQuaternion. But names are a minor point. Though I prefer > isometry/rigidtransform over dualQuaternion. 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 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. >> 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. 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... >> 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. >> >> 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. >> 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

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

**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

**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/ |