Kaya Kupferschmidt wrote:
> thank you for your reply. So I had to experiemtn with the methods
> myself, and I guess I found the bug.
>
> To me it seems as if Matrix::setTransformat applies the components
> in the following order:
> 1. Scale
> 2. Rotate
> 3. Translate
> But Matrix::getTransform returns components for the following order:
> 1. Rotate
> 2. Scale
> 3. Translate
interesting, thanks for investigating that.
> I was able to work around this inconsistency by postprocessing the
> values returned by getTransform as follows:
>
[snip]
> Then the variables translation, rotation, scale, scaleOri together
> with center contain the correct values to be fed into
> Matrix::setTransform such that the original Matrix is reconstructed.
>
> Maybe this will help some other people, too. Of course the best
> solution would be to fix the OpenSG matrix decomposition, such that
> the correct values will be computed.
I agree. Maybe with what you have discovered it is possible to find the
problem, I'll try to get to it soon, thanks again for looking into it
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
