[eigen] Do we need geometry refactoring? |

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

*To*: Eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: [eigen] Do we need geometry refactoring?*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Thu, 29 Jul 2010 12:56:46 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=LxznUC1FLFe4FhsvcV2EO5PlwxA1cIxTF7SfECi5pCU=; b=Lmyx/neC1XyoOEgZRgJRyIQc6zKc3t96boYePGEnx/vmgl+CWUpUEVIsfBuuKdPVZv uvI7vbgTBZndYNu/Bna3LhN9BVmuqsRX7hUoBli/vGzLKNz2Q1aK7xXodJEG7PK1W4o0 QScAImrq1J1fHNzUbXySU1s03RVfTlRUaJbFE=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=a6Bvtn3I7PHQqLuHMKw58Ds1q+QwU9nixvEAAQS2UfW6inHMAT66qPTtI9SPKhSY1a h26T7AiMQkjx4nAF+KKNBG8RGDSe8voEAAkYstOoGoV+9Y2D59OQWxG5NfSZAMB4jMEg LNk+1S8Uw5TNQpRmsZrd1uwUgManID0RrEx+w=

Hi, I was once again working a bit with the geometry module and stumbled over a few tiny issues. 1) I discussed this before with Gael but did not commit yet so I am repeating it here. We think it makes sense to default transformation modes to Projective. This is more generic and safer. 2) Unifying member access. We have several classes that behave like matrix transformations in the sense that they define the required products in order to mimic a matrix. The core class is Transform and transforms allows the user to access the underlying matrix in several ways Transform::matrix() returns a homogeneous representation of the transform Transform::linear() returns the upper left Dim by Dim component of the matrix Transform::translation() returns the translation, upper right Dim by 1 But what about other classes, how about e.g. Translation? Translation allows to access the data via a single function called Translation::vector() - this is not very intuitive. And I would prefer another function Translation::translation() That may sound redundant, but it would be following what we do in transform. We could even offer Translation::matrix() and return a read-only identity. This function is one step towards being able to interchange types as Isometry3f and Translation3f (in case the isometry were just a translation). Ok, the question is actually whether we want Translation, Quaternion, etc. behave like Transformations? Should we allow the same initialization as well, so would it make sense to allow initialization of a translation from a (Dim+1) by (Dim+1) matrix? 3) This is more like a tiny question. Why are we setting the projective part of the matrix to 0 ... 0 1 in the inverse method? I think it is absolutely useless since it should already be like that... - Hauke

**Follow-Ups**:**Re: [eigen] Do we need geometry refactoring?***From:*Adolfo Rodríguez Tsouroukdissian

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] licensing: watching the MPL update process** - Next by Date:
**Re: [eigen] Do we need geometry refactoring?** - Previous by thread:
**Re: [eigen] licensing: watching the MPL update process** - Next by thread:
**Re: [eigen] Do we need geometry refactoring?**

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