Why only rotation in degrees?

Started by
1 comment, last by Trienco 9 years, 5 months ago

Hi,

I am playing a little bit around with OpenGL.

To store a rotation there are three possibilities quaternions, direction vectors and euler angles.

Normaly I would take "direction vectors" as they cover the rotation of an object as well as the movement direction "p(x, y) = v(x, y) * speed" and that is all you need, right?

However in android the two standard classes "Matrix4f" and "Matrix" are only covering rotation with euler angles in degree, and this is something I do not get!

Why euler angles?

That means everytime I compute a new direction I have to calculate and store a direction vector as well as the rotation in degree?

They are calculated into a direction vector again in the matrix classes according to the source of them, so I do not get why they thought it would be a good idea to input a rotation in degrees when I need the direction vector nonetheless.

They can't describe a movement direction, right?

Can I do something like this: (?)


calculate() {
     matrix.reset(); // location 0, 0
     matrix.moveForward( 10 );
     matrix.turnBy( 90 );
     matrix.moveForward( 10 );
     matrix.turnBy( 90 );
     // location 0, 10; roation 180° ?
}

moveForward( float x ) {
     matrix.translate( x, 0 );
}

turnBy( float angle ) {
    matrix.rotate( angle );
}

Then I would understand why rotation in degrees might be useful as I wouldn't need a direction vector then and could rotate my object easily by "rotation += r"

I tried it but it doesn't seem to work. The first rotation works fine, however the second roation isn't 90° (or 180° in total) anymore, so I guess I have to store and compute the x, y and rotation values seperatly and calculate the matrix when needed.

I hope the problem I have is clear, I just feel like I am missing something when working with matrices. Their only use can't be just being a complicated storage for the GPU while the CPU has to calculate those everytime for every object using the x, y and roation value of every object right before it is drawn, this is such a huge performance killer...

Thank you very much

Icy

Advertisement

Those classes come from your code, not from OpenGL. (Or perhaps OpenGL ES, if that is the flavor you prefer.)

The questions are not things normally handled by OpenGL, but instead handled by your own math libraries.

When OpenGL operations require an angle, they near-universally require the angle in radians, not degrees. For quaternions, there are only a small number extensions that allow them, but an increasing number of popular shaders take them as parameters. I'm not aware of any function in the core API that accepts them.

In this case you seem to be referring to the Android SDK's class android.opengl.matrix, those are just a collection of static methods for manipulating float arrays. They aren't spectacular and games typically use their own libraries instead. They are extremely rudimentary classes for some basic functionality, but they are not high performance nor are they comprehensive of what most developers need.

You also seem to be referencing the android.renderscript.Matrix4f functionality, which is useful if you are using RenderScript, but it isn't directly portable with the OpenGL ES stuff.

Take a long look at the actual vectors that make up your rotation matrix. Eventually you should notice (depending on how your game defines its axes) that the rotation matrix is nothing else but the forward, right and up direction vectors. No point in additionally storing angles. If you need to apply the rotation, just use the matrix, if you need to move, just use the vectors from the matrix. That's basically the benefit for using a representation that is more wasteful than others (angles, quaternions, two vectors).

One major downside if you keep accumulating rotations in a matrix is that small errors will also accumulate and force you to re-orthonormalize the matrix every once in a while.

f@dzhttp://festini.device-zero.de

This topic is closed to new replies.

Advertisement