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: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] 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 <shaotianlan...@gmail.com> 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
