Re: [eigen] geometry module |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] geometry module*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Tue, 7 Sep 2010 06:57:28 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Byb67A/cF+21FALbAG0vo7SiIDTbuF5aL2jydkrCnOo=; b=Lkv26EOsps5ROukH78qMTqNbnQxZJRKNlgRU9jbEMpw9Gs8CbeLhsBO5/IDlCdNb/Y 6SJA0zsAGScoPX2BSkfgB031jixMILUMci2KnEHb2XA8dcVUZyianthGZV8BTpV9dKi1 OrKrB8S79blGDRLj+1+wP7WCCJ4r64/aV4T1I=*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=nacLWD26pHA0vYVfSNQgPZ39M8bjkOY8Goi7H9kGncG1qc/AVdOaRIMLz5jfk1llGm LxiFFoNOhbWK+OliFmAYPCg6mUorr1U7VAKiU61zCJsU3au0IDiiRQHMoV60Qj2JlcvT 8NcM0XxXrfWqOT2snpfIHENiMoaoM1SZTuo6g=

2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>: > As I mentioned in the previous email, I've been having a gander at the > new geometry module. Not sure who's putting it together, but wondering > if they'd mind me picking their brain a bit. > First of all, the Transform class is for transformations represented by matrices i.e. homographies. It's not a statement that no other representation is interesting, it's just what this class is doing. Other representations may be added as separate classes. > We're using transforms for robotics, so strictly rotations and > translations. A 2D setup might only need 3 variables, angle + x-trans > + y-trans. The problem with representing a transformation using an angle, is that subsequent computations are relatively slow as one needs to compute cosines and sines. If however you're OK with representing the angle as a (cosine, sine) pair, then Rotation2D is doing that. If you want a class that combines a Rotation2D with a translation vector, which could be called Isometry2D, indeed we don't currently have that. > A 3D setup could most efficiently run with quaternion + 3 > element vector for translation. Here, "most efficiently" depends on what you're doing. If you want to apply this transformation to a vector, it's going to be faster if you have a matrix representation of your transform, as the Transform class does. This is one of the most performance-critical use cases... That said, either what you propose (quaternion+vector) or a "dual quaternion" class as has been discussed previously on this list, would be interesting. We just happen not to have that yet. I think that given sufficiently explicit names, different classes can coexist. The name Transform may not be very explicit though, but the matrix approach is the only one to be generally applicable (any size, no assumption on the transformation...) so that warrants a relatively generic name. > I see that some optimisations are > being made to the transform class - e.g. CompactAffine. There is also > Isometry - how exactly does this differ from the Affine types, Isometry means Affine from the point of view of storage. The only difference is that if you use Isometry, then you guarantee that the transformation is actually an isometry, i.e. an orthogonal transformation + translation vector. This allows Eigen to generate faster code for certain operations like inverse(). By the way --- others: shouldn't Isometry be CompactAffine instead of Affine? Or should there be a CompactIsometry, etc. > and > was/is there any design thoughts behind more optimised > storage/calculation processes (i.e. quaternion instead of 3d rotation > matrix, angle value instead of 2d rotation matrix)? as said above: - for 3d isometries, quat+vector or quat+quat have been discussed previously, would be a welcome addition - for 2d isometries, angle is inefficient, combining Rotation2D+vector is the right approach. Benoit > > Many thanks, > Daniel Stonier. > > -- > Phone : +82-10-5400-3296 (010-5400-3296) > Home: http://snorriheim.dnsdojo.com/ > Yujin Robot: http://www.yujinrobot.com/ > Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl > > >

**Follow-Ups**:**Re: [eigen] geometry module***From:*Daniel Stonier

**Re: [eigen] geometry module***From:*Mathieu Gautier

**Re: [eigen] geometry module***From:*Gael Guennebaud

**References**:**[eigen] geometry module***From:*Daniel Stonier

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Benchmarking** - Next by Date:
**Re: [eigen] Benchmarking** - Previous by thread:
**[eigen] geometry module** - Next by thread:
**Re: [eigen] geometry module**

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