Why is it better to explicitly manage matrices in OpenGL?

Question

Recently, I have been quite a bit versed in OpenGL, and I came across a section that allows OpenGL to manage presentation / model / projection matrices or to manage them independently, either using its own matrix implementation or using a library like GLM. I saw that many large projects have their own camera control (i.e., manage their translations, rotations, etc.). I can understand why this will help to provide complete control over the system, but also, it seems like a lot of work for little gain.

Why is it better to do your own management than using the built-in functions of OpenGL? Obviously, this is due to the shader pipeline, not the default fixed function.

(This applies to any 3D library).

Answer 1

(On the OpenGL side, ES 2 does not have a conversion management tool, so in some cases you have no choice.)

More about the fact that I found control matrices through the built-in OpenGL stack matrices has become a real pain from time to time, forcing me to push and pop quite abundantly in the more complex parts of my rendering code, even reordering the rendering sometimes just to simplify stack management. I also wrote a C ++ class pusher-popper that uses RAII to automatically manage all of this, but this requires a careful definition of local variables.

When I switched to ES 2, I was dismayed to learn that all of these features had disappeared. However, I found that switching to my own matrices actually simplified my code, because I could work with several transformations using a combination of local and member variables (with meaningful names) without losing space, and the transformation stack was replaced with the main one using the call stack - i.e. the current transformation is just a local matrix variable that is passed as the parent parameter of the transformation for the next function down - but with the flexibility to do it differently at another time.

Answer 2

This is best for a large list of reasons. A recent Apple presentation on OpenGL enhancements in OSX Lion says this is best: the new OpenGL specs (mostly 3.2 inches) are better aligned with what GPUs do. In OpenGL 2.1, all operations with matrices are performed on the processor. Thus, not only is there no magical accelerated benefit from the use of GL matrices, you are locked into a completely arbitrary matrix control model: only projection matrices and model matrices (for vertices), restrictions on the size of the matrix stack, a limited set of matrix operations, etc.

When you start managing your own matrices, you begin to understand why this is so much better. As your scenes become more complex, you begin to see the need for additional matrix caches (in addition to the "projection" and "model view"). You open up possibilities for creating more useful matrix functions. For example, what sounds more enjoyable to use? glRotatef(90.0f, 1.0f, 0.0f, 0.0f); or matrix.rotateX(90.0f); ? I was always worried that I had to indicate the axis of rotation every time!

When you begin to recognize the difference between CPU operations and GPU operations, you will understand how to manage your own matrices.

Answer 3

The matrix stack controlled by GL is deprecated in recent versions. OpenGL specifications. Therefore, going forward, managing them yourself is the only option.