Hi Thomas, Thank you very much for your support! I'd like to add an argument here. The document of the getRotate() function says: /** Get the matrix rotation as a Quat. Note that this function * assumes a non-scaled matrix and will return incorrect results * for scaled matrixces. Consider decompose() instead. */. But there's no such warning for the getScale() function. Therefore I would expect the getScale() function just gives the previously set scale vector back, regardless of the rotation.
Apparently changing a 9 year old function could break some code. But I think if the change of getScale() would be made, most applications won't be affected. Because in overwhelmingly common case, the scale factors are the same in all directions. In such case, the (unintended) transpose makes no difference because of the properties of orthogonal matrix. Best regards, Tianlan Shao On Fri, Apr 18, 2014 at 4:27 PM, Jolley, Thomas P < [email protected]> wrote: > Hi Robert, > > I think Tianlan may be correct about the getScale function. Here's why: > > The osg Matrix class was written as row major ordering (layout in memory > is column major so it works with OpenGl). If you look at the matrix in row > major order with the rotation matrix separated from the scaling it will > look something like this > > Sx { r00, r01, r02, 0 } > Sy { r10, r11, r12, 0 } > Sz { r20, r21, r22, 0 } > 1 { x, y, z, 1 } > > This assumes the 3x3 rotation matrix, r, is properly normalized and no > skew. > > To get the X scale, Sx, value you need to get the length of the top row > from the matrix. The current getScale function gets the length of the left > column (of the rotation matrix only). The getScale function also swaps > rows and columns when getting the Y and Z scale. To me, it looks like the > getScale function improperly transposes the 3x3 rotation matrix. > > Is there anyone using the getScale function? > > ---- > Tom Jolley > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Robert Osfield > Sent: Friday, April 18, 2014 2:06 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] A suspicious bug of MatrixD > > HI Tianlan, > > On 17 April 2014 23:04, Tianlan Shao <[email protected]> wrote: > > I still have doubt about the interpretion of the experiment: "...so > > we'd expect the scale of the x and y axis to be swapped.". I think > > that means, after rotation, the scale is still represented in the > > original frame, instead of the rotated one (otherwise the scale would > > be independent from the rotation). But when the rotation is, say, 30 > > degree, then the scale cannot generally be represented in the original > > frame without introducing sheering. > > You can't have a scale independent of rotation, you have to either choose > to do the scale from the perspective of the pre or post multiplication. The > current implementation tells us how an x,y,z axis will be scaled when > multiplied in the form v' = M*v which is consistent with the row major > ordering used by the OSG. > > > > Another argument is that the current Matrixd::getScale() is > > INconsistent with Matrixd::decompose( ). The following is the test > > code, which shows that the result of getScale() is not the same as > > decompose(), whereas getTrans() gives consistent result. This behavior > is somewhat confusing for me. > > The decompose method is able to compute a rotation so applies this within > it's S*R*T decomposition, the getScale() method assumes no rotation so will > give you a different result if you apply a rotation, so this in itself > dosn't surprise me and is what I'd expect. > > > > > In summary, I think the newly proposed version of getScale() gives > > (the > > correct) rotation-independent scale information, which results in > > similar behavior as that of getTrans() and decompose(), and is > > probably more intuitive to use. > > There is no such thing as rotation-independent scale unless you have a > uniform scaling so I'm not sure where you going with what you are expecting. > > What you are asking for the getScale() to be different from what it is, > and consistent with the decompose(). I believe the current > getScale() code is consistent and correct in itself - changing it would > endanger breaking user code that relies on the current interpretation. If > one attempts to use it in place of decompose then you'll get different > results - this inconsistency is unfortunate but this is perhaps more down > the illusion that the two are interchangeable when they aren't. > > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
