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 22:20:22 +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=WewDjgEQf9rOdZEZ7jxkaXYWQhX9PIcVpv4QSDn6eTA=; b=ETJzkpFyq+UCRr1cMUf3Ti21uSwx6VFNrO+k1va+NjrvfYOf3FsUWj29Y6CafqCyrf DQvp4cpYgOVl3G4T3L577VY91nDA8ykgNGnpqVtMEnNGzlUxrRiUdsNzTam/4fv2UKlH b/mTaMhGC1JP5o3EG1RiKOXt25iDNiLtRyP/o=*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=BBb4EdHRIRoaMhFeUf//ZbOKKticTexi2tWNXSmt4U7jreKo90NY8hS54SaS8R0YMo e8ViKlmJxOhYZzijMHBEyy3bjnIi4qZlJJ1NpDs5g+BA0rRePty1GnlG4PNnCfNnTqKR YabHIUJcfoYy1YWPyLM1wvg5r+2n9jLl2HGZ4=

On Thu, Sep 17, 2009 at 9:56 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: > 2009/9/17 Rohit Garg <rpg.314@xxxxxxxxx>: >> What do others here think about this. Is the API, the unit tests etc. >> good enough for inclusion in eigen? > > OK, indeed RigidTransform.h looks good, but: > > 1) please indent only with spaces, not tabs Yeah, will run it thru indent. :) > > 2) absolutely need the standard comment at the top with your copyright > and the licensing blabla I know, this is just a base for testing and it is in the form so that I can use independent of it''s use in eigen. > > 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. > > 4) You implement operator+ returning by value. That raises 3 questions. > a) The sum of two rigid transformations isn't rigid anymore, so if you > keep the name RigidTransform, you can't have an operator+. So I'll have to call it dualQuaternions, huh? OK. > 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. > c) we need to adopt a uniform policy, either we have such operator+ > returning by value in both DualQuaternion and Quaternion, or in > neither. But....., it is needed. :| > 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. > > 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. > > 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. > > *** > > Here's a little idea to make it more easy for the user to do his own > operations like sum. > Currently you have two member quaternions so it's not easy for the > user, e.g. if he wants an optimized sum he must do: > dualquat.quat[0].coeffs() + dualquat.quat[0].coeffs() > dualquat.quat[1].coeffs() + dualquat.quat[1].coeffs() > etc... > > Instead you could have only one data member, that would be a vector > m_coeffs of size 8. You would have a method coeffs() returning a > reference to it. So the user could do, just like with quaternions, > dualquat.coeffs() + dualquat.coeffs() > > Now how do we address the individual quaternions ? You would have > member methods quat0() and quat1() returning quaternion references > obtained with the reinterpret_cast trick. > > QuatType &quat0() > { > return *reinterpret_cast<QuatType*>(&m_coeffs); > } > > QuatType &quat1() > { > return *(reinterpret_cast<QuatType*>(&m_coeffs) + 1); > } > > By the way, are there more human friendly names for quat0 and quat1 ? > Or perhaps they really don't have any simple geometric interpretation? 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. > > 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

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

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