then I'll have to check the source of the collision manager...
I guess I can extract just that function instead of creating a complete collision manager...
I had to reverse my rotation order in the render loop from ZYX to XYZ... but when I change the order in the matrix instead the calculation gives wrong values...
no big deal I can live with the render order XYZ... but I have to change a few other things also now...
ok, I made some test cases on Irrlicht, and then the same with my Java code... and it turned out, the calculations were correct (same results)... :shock:
and now I get THIS: https://www.youtube.com/watch?v=VrErHDAswP0
I hope you don't mind having one last look at this video... I won't bother you ...
I tried each possible multiplication order (TXYZ, TZYX, XYZT, ZYXT)...
I also tried with/without scale...
I ported all needed functions from the Irrlicht matrix to Java...
no success !!!
the matrix array goes from 0 to 15 for both (DX and OGL)... how they are interpreted internally is irrelevant, 0-3 is either a row or a column, but it's always the same (0-3) in the array !!! :D
LH or RH doesn't matter at the moment... if the result rotates the wrong direction I ...
ok, I had a look at Irrlicht's matrix4 for this methods... and I guess I'm getting closer !!! this methods use trigonometry, and it seems exactly what I want !!!
this are the three methods I need: inline CMatrix4<T>& CMatrix4<T>::setRotationAxisRadians( const T& angle, const vector3d<T>& axis ...
yeah, I had a look at it... but I can't use it, because OpenGL Matrix doesn't have the methods you're using there... :shock: like rotateVect() and setRotationAxisRadians()...
I guessed they may are called differently... so I tried (guessed) what methods it could be for the OGL matrix and came up ...