[no subject]

Also, perhaps we can keep both API ?

that's all folk, what do you think ?

gael.

------=_Part_10255_12608867.1219834051479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br>Hi list,<br><br>if we still agree that Eigen should be as close as possible to what people would write on a piece of paper, then I think Transform is poorly designed.<br><br>For instance if you want to concatenate a scale S to a transformation T you would write:<br>
<br>paper:&nbsp; T&#39; = T * S<br>or <br>paper:&nbsp; T&#39; =&nbsp; S * T<br><br>while in Eigen we currently have to write:<br><br>eigen:&nbsp;&nbsp; T = T.scale(Vector3f(sx,sy,sz));<br>or<br>eigen:&nbsp;&nbsp; T = T.prescale(Vector3f(sx,sy,sz));<br><br>
What about doing something similar to what I did with rotations and overloading the correct *= and * operators such that you could write:<br><br>eigen:&nbsp;&nbsp; T = T * Scale3f(sx,sy,sz);<br>eigen:&nbsp;&nbsp; T *= Scale3f(sx,sy,sz);<br>
or<br>
eigen:&nbsp;&nbsp; T = Scale3f(sx,sy,sz) * T;<br><br>then if you want to express:<br><br>paper: T = S * R * L;<br><br>(where L is a translation)<br>you could write:<br><br>eigen:&nbsp; T = Scale3f(..) * RotationType(....) * Translation3f(...);<br>
<br>(with RotationType in {Quaternion, Matrix, AngleAxis, Rotation2D } )<br><br>instead of the current:<br><br>eigen:&nbsp; T.setIdentity();<br>eigen:&nbsp; T.scale(...);<br>eigen:&nbsp; T.rotate(...);<br>eigen:&nbsp; T.translate(...);<br><br>
ok, actually the rotate, scale and translate methods return a reference to T, so currently you can still write:<br><br>eigen:&nbsp; T.setIdentity();<br>
eigen:&nbsp; T.scale(...).rotate(...).translate(...);<br><br>that is not too bad in that case, but think about &quot;T = R1 * L * T * R2&quot; which involves &quot;pre*&quot; versions of the methods:<br><br>
eigen:&nbsp; T.pretranslate(L).prerotate(R1).rotate(R2);<br><br>IMHO it&#39;s quite confusing because it does not give you the idea of the transformation order: &quot;R1 * L * T * R2&quot;.<br><br>From a practical point of view we alrealy have all the RotationType, and we only need to overload the operators as well as to define two wrapper classes Scale and Translate. I&#39;m only a bit scared about a amount of combinations to handle... though all products involving two different transformation types will generate a Transform, so that&#39;s certainely doable.<br>
<br>Also, perhaps we can keep both API ? <br><br>that&#39;s all folk, what do you think ?<br><br>gael.<br><br></div>

------=_Part_10255_12608867.1219834051479--