ISceneNode local transformation design choice

cheshirekow · Post by **cheshirekow** » Fri Aug 07, 2009 2:11 pm

So I'm looking at the source and, in particular, I'm curious why local transformations are stored as rotation angles, translations, and scale separately, rather than using a transformation matrix like with the absolute transformation. Any of the devs want to shed some light on that?

I'm wanted to make a "Satellite" node animator that causes one scene node to "orbit" another, and allows for increasing/decreasing the altitude, inclination, and precession of the orbit incrementally. Changing the inclination of the orbit is easy using the system as it's set up, but changing the inclination and the precession arbitrarily (and incrementally) isn't straightfoward and even impossible for some values due to singularities in euler angles near high inclination. If the local transformation were stored as an accessible (retrievable, settable) transformation matrix, I could perform the necessary atomic operations pretty easily.

I'm going to try to put together a custom IHomogeneousSceneNode that does store the local transformation as a matrix, but I'm wondering what was the reasoning was in choosing to use rotations, position, and scale rather than a transformation matrix. If this was due to the hassle of people not understanding matrix transformations and trying to provide a more readily understandable interface, or to prevent engine users from attempting to set invalid transformations, then that's cool I will be on my merry way. However, if there is some reason specific to the engine design that would affect compatibility down the line, it would be nice to know about it before I get too invested in the customized classes.

Any insight would be greatly appreciated.

hybrid · Post by **hybrid** » Fri Aug 07, 2009 4:33 pm

check your matrices, and tell me how you can change the scale after you changed the rotations... BTW: The CDummyTransformationSceneNode already sotres everything in a matrix, so don't invent too much new.

cheshirekow · Post by **cheshirekow** » Fri Aug 07, 2009 5:37 pm

tell me how you can change the scale after you changed the rotations...

Starting with a transformation T1 (4x4 matrix), and given a rotation of R (4x4 matrix with the last column and last row zero except for for the 4,4 element which is unity) from the local frame, the new transformation T2 will be: T2 = R*T1, and will preserve the scaling. The R can be generated by composition of atomic rotation using user input.

Code: Select all

    R_x = | 1.0         0.0         0.0     |
          | 0.0         cos(dx)     sin(dx) |
          | 0.0         -sin(dx)    cos(dx) |
    
    R_y = | cos(dy)     0.0         -sin(dy)|
          | 0.0         1.0         0.0     |
          | sin(dy)     0.0         cos(dx) |

Where dx and dy are the angles of rotation around the x and y axis (actually i think x and z in irrlicht) and are proportional to the mouse input. Since the angles are small, we can just say R = R_x * R_y.

We could also generate the rotation from an angular velocity vector in the case that the node is "spinning" (i.e. not controlled by the mouse) by first removing the scaling, applying the rotation and then reapplying the scaling. We find the scaling by taking the dot product of each column of the 3x3 top-left block of transformation matrix with itself.

CDummyTransformationSceneNode already sotres everything in a matrix, so don't invent too much new.

Excellent! Looking at the class, that's exactly what I wanted. Not re-inventing the wheel was my reason for asking. I wish I'd seen this myself, but thanks for pointing that out to me. It does not appear, however, that there is a version of CAnimatedMeshSceneNode or CCameraSceneNode that derive from CDummyTransformationSceneNode, so if I want to use CDummy... I will have to reimplement those concrete classes, is that correct? I do not see any derived classes listed under IDummyTransformationSceneNode in the doxygen in fact...

hybrid · Post by **hybrid** » Fri Aug 07, 2009 5:41 pm

Oh, you cannot do a mtrix multiplication in each step, that would be far too expensive. And if you need to query scale, you have to get those values back from the matrix with whichever rotation (even three rotations!) was made. This is computationally expensive and error (precision) prone

cheshirekow · Post by **cheshirekow** » Fri Aug 07, 2009 7:11 pm

Interesting. On such small matrices I didn't figure there would be a big difference in the number of operations. I will accept that as the case, however.

As for the scaling, I see how storing all the information in a single matrix would lead to drifting scale factor after successive operations, but That could be avoided by storing the scale matrix and the rotation matrix separately, possibly along with a third, combined form to avoid having to multiply them together more than once per update. It would increase the size of the data structure pretty significantly though.

hybrid · Post by **hybrid** » Fri Aug 07, 2009 11:28 pm

Yeah, as we now only store 5*3 vectors, which is almost just one matrix. So keeping this habit might save much space and lead to some performance increases at some points. However, saving the rotations as quaternions might help. A proper flow needs to be defined, though.

cheshirekow · Post by **cheshirekow** » Sat Aug 08, 2009 1:38 am

Yeah, quaternions avoid the singularities of Euler angles without a huge increase in size, and quaternions multiplication is well defined. The only drawback is the derivatives aren't very clean... Not a problem if you don't need them.

Thanks for the insight.

Dorth · Post by **Dorth** » Sat Aug 08, 2009 6:39 am

If it's the size you are worried about, you can fold a quaternion in 3 numbers. However, using it in that form is impossible. So with quaternion it's always a trade off between size (3 numbers) or ease of use (4x4 matrices) (you can store it as 4 numbers, mind you, it ain't that much bigger.)