Dear Robert,
I'd like to add that, when the x, y, and z scale factors are identical, the
current getScale() gives the same result as the newly proposed one. I guess
that's the reason why this issue was not reported before.
Thank you very much.
Best regards,
Tianlan Shao
On Fri, Apr 18, 2014 at 12:04 AM, Tianlan Shao <shaotianlan...@gmail.com>wrote:
> Dear Robert,
> thank you very much for your time.
>
> 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.
>
> 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.
>
> /**********Test Code**************/
> osg::Matrixd S = osg::Matrixd::scale(3.0, 4.0, 5.0);
> osg::Matrixd R =
> osg::Matrixd::rotate(osg::inDegrees(30.0f),osg::Vec3d(0.0,0.0,1.0));
> osg::Matrixd T = osg::Matrixd::translate(7.0, 8.0, 9.0);
>
> osg::Matrixd mat = S*R*T;//combine scale, rotation, and translation
>
> std::cout <<"getScale() = "<< mat.getScale().x() << " "<<
> mat.getScale().y() << " "<< mat.getScale().z() << std::endl;//looks strange
>
> osg::Vec3d x_vec2(mat(0,0), mat(0,1), mat(0,2));
> osg::Vec3d y_vec2(mat(1,0), mat(1,1), mat(1,2));
> osg::Vec3d z_vec2(mat(2,0), mat(2,1), mat(2,2));
> std::cout<< "new_getScale() = " << x_vec2.length() << " "<<
> y_vec2.length() << " " << z_vec2.length() << std::endl;//3 4 5
>
> osg::Vec3d trans;
> osg::Quat rot;
> osg::Vec3d scale;
> osg::Quat so;
> mat.decompose(trans, rot, scale, so);
>
> osg::Vec3d trans2 = mat.getTrans();
>
> //The result of getTrans() is consistent with decompose()
> std::cout << "decomposed Trans "<< trans.x() << " "<< trans.y() << " " <<
> trans.z() << std::endl;//7 8 9
> std::cout << "getTrans() = "<< trans2.x() << " "<< trans2.y() << " " <<
> trans2.z() << std::endl;//also 7 8 9
>
> //The result of getScale() is INconsistent with decompose(), with is
> confusing
> std::cout << "decomposed scale "<< scale.x() << " "<< scale.y() << " " <<
> scale.z() << std::endl;//3 4 5
> std::cout << "decomposed so "<< so.x() << " "<< so.y() << " " << so.z()
> << " " << so.w() << std::endl;//zero rotation
> /**********End of Test Code*************/
>
> 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.
>
> Thank you again for your precious time.
>
> Best regards,
> Tianlan Shao
>
> On Thu, Apr 17, 2014 at 4:26 PM, Robert Osfield
> <robert.osfi...@gmail.com>wrote:
>
>> Hi Tianlan,
>>
>> I have done the following test where I provide a non unifom scale
>> matrix then rotate it by 90 degrees, and then output the result of
>> getScale() and the result of you suggested above:
>>
>> osg::Matrixd scale_then_rotated =
>>
>> osg::Matrixd::scale(3.0,4.0,1.0)*osg::Matrix::rotate(osg::inDegrees(90.0f),osg::Vec3d(0.0,0.0,1.0));
>> OSG_NOTICE<<"Matrixd.getScale() =
>> "<<scale_then_rotated.getScale()<<std::endl;
>>
>> osg::Matrixd mat(scale_then_rotated);
>>
>> osg::Vec3d x_vec2(mat(0,0), mat(0,1), mat(0,2));
>> osg::Vec3d y_vec2(mat(1,0), mat(1,1), mat(1,2));
>> osg::Vec3d z_vec2(mat(2,0), mat(2,1), mat(2,2));
>>
>> std::cout << x_vec2.length() << " "<< y_vec2.length() << "
>> "<<z_vec2.length() << std::endl; //seems correct
>>
>> The result I get on the console is:
>>
>> Matrixd.getScale() = 4 3 1
>> 3 4 1
>>
>> The getScale() version is correct, your suggestion is wrong as the
>> matrix is now rotated 90 degrees so we'd expect the scale of the x and
>> y axis to be swapped.
>>
>> If you were to compute the rotation and then remove this rotation and
>> then do the getScale() I believe you'll get the result you are looking
>> for with the existing code.
>>
>> Robert.
>>
>>
>>
>> On 17 April 2014 13:53, Tianlan Shao <shaotianlan...@gmail.com> wrote:
>> > Dear Robert,
>> > thank you for your reply, below is the code to reproduce the bug:
>> >
>> > /********************************************************/
>> > osg::Matrixd S = osg::Matrixd::scale(3.0, 4.0, 5.0);
>> > osg::Matrixd R = osg::Matrixd::rotate(osg::Quat(0.1, 0.5, 0.6, 0.7));
>> > osg::Matrixd T = osg::Matrixd::translate(7.0, 8.0, 9.0);
>> >
>> > osg::Matrixd mat = S*R*T;//combine scale, rotation, and translation
>> >
>> > std::cout << mat.getScale().x() << " "<< mat.getScale().y() <<
>> > mat.getScale().z() << std::endl;//Oops...seems wrong
>> >
>> >
>> > osg::Vec3d x_vec2(mat(0,0), mat(0,1), mat(0,2));
>> > osg::Vec3d y_vec2(mat(1,0), mat(1,1), mat(1,2));
>> > osg::Vec3d z_vec2(mat(2,0), mat(2,1), mat(2,2));
>> >
>> > std::cout << x_vec2.length() << " "<< y_vec2.length() <<
>> z_vec2.length()
>> > << std::endl; //seems correct
>> > /********************************************************/
>> >
>> > If the matrix combination above makes sense, then I guess what I found
>> is
>> > indeed a bug.
>> > Thank you for your time and work.
>> >
>> > Best regards,
>> > Tianlan Shao
>> >
>> >
>> > On Thu, Apr 17, 2014 at 11:36 AM, Robert Osfield <
>> robert.osfi...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Tianlan,
>> >>
>> >> Could you provide a small example that illustrates the problem?
>> >>
>> >> I did a quick test of:
>> >>
>> >> osg::Matrixd matrix = osg::Matrixd::scale(3.0,4.0,1.0);
>> >> OSG_NOTICE<<"Matrixd.getScale() =
>> "<<matrix.getScale()<<std::endl;
>> >>
>> >> And this works. I will need to have a think about a more complex
>> >> scale set up before I can judge what it should be.
>> >>
>> >> Robert.
>> >>
>> >> On 15 April 2014 16:43, Tianlan Shao <shaotianlan...@gmail.com> wrote:
>> >> > Dear all,
>> >> > The following code in the header file MatrixD looks very suspicious
>> to
>> >> > me:
>> >> >
>> >> > inline Vec3d getScale() const {
>> >> > Vec3d x_vec(_mat[0][0],_mat[1][0],_mat[2][0]);
>> >> > Vec3d y_vec(_mat[0][1],_mat[1][1],_mat[2][1]);
>> >> > Vec3d z_vec(_mat[0][2],_mat[1][2],_mat[2][2]);
>> >> > return Vec3d(x_vec.length(), y_vec.length(),
>> z_vec.length());
>> >> > }
>> >> >
>> >> > Shouldn't the index order be the other way around? I mean it should
>> be
>> >> >
>> >> > inline Vec3d getScale() const {
>> >> > Vec3d x_vec(_mat[0][0],_mat[0][1],_mat[0][2]);
>> >> > Vec3d y_vec(_mat[1][0],_mat[1][1],_mat[1][2]);
>> >> > Vec3d z_vec(_mat[2][0],_mat[2][1],_mat[2][2]);
>> >> > return Vec3d(x_vec.length(), y_vec.length(),
>> z_vec.length());
>> >> > }
>> >> >
>> >> > The behaviour of my program was strange before I fix this problem.
>> I'm
>> >> > not
>> >> > 100% percent sure, but since it's of fundamental importance, I still
>> >> > decided
>> >> > to report.
>> >> >
>> >> > Best regards,
>> >> > Tianlan Shao
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
