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
