3d rotation and moving using 4x4 matrices. Relevant?
-
I’ve been reading articles and I came across a few that said a good way to do 3d rotations and translations is by using matrices, like in this post here : https://stevehazen.wordpress.com/2010/02/15/matrix-basics-how-to-step-away-from-storing-an-orientation-as-3-angles/
It’s a bit over my head but I think I understand it. I’m just not sure if this applies to Fuze at all. What do the experts think?
-
That tutorial does explain 3d programming quite well, in general.
To utilize it in Fuze, you would want to think how to "convert" from the XNA language and structures, to what is available in Fuze.
I likewise prefer to think in terms of matrices like this (over, for example, quaternions). In Fuze, I made structs for 3x3 matrices, and then functions for matrix multiplication.
To rotate objects in Fuze, then, I have used my 3x3 matrices to manually keep track of an object's orientation (up, right, and forward vectors). Then, careful application of the Fuze function rotateObject, to get the graphics to align with my calculated orientation!
-
I’ve remembered it’s because I’m thinking about things exploding outwards and bouncing off objects and having angular momentum eventually rolling to a stop, which I can’t do with objectPointAt() like I normally use.
Why do you use 3x3 matrices instead of 4x4 like that blog post? Is the way you do it significantly expensive, performance-wise?
-
Honestly, I use 3x3 because my mind can make more sense of it that way!
In a framework like XNA or the like, that directly interface with the GPU, the 4x4 approach does have a performance advantage, since it handles rotation and translation together, and the matrix multiplication is very fast.
I have not experimented with 4x4 in Fuze, but my instinct suggests that there would not be a performance benefit, since in either approach (3x3 or 4x4) you have to code the math manually.