CODEWITHSUNDEEP
c++copenglmatrix
jli
jli

Reputation: 6623

Why is it better to explicitly manage matrices in OpenGL?

Recently I've been messing around a fair amount with OpenGL, and I have come across the split between allowing OpenGL to manage the view/model/projection matrices or managing them yourself, either with your own matrix implementation or a library such as GLM. I've seen that a lot of large projects have their own camera management (i.e. manage their own translations, rotations etc.). I can see why it would help for making sure you have full control of the system, but besides this it seems like a lot of work for a marginal gain.

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

(This would apply to any 3D library).

Upvotes: 6

Views: 970

Answers (3)

TheBuzzSaw
TheBuzzSaw

Reputation: 8826

It is better for a large list of reasons. Apple's recent presentation on the OpenGL improvements in OSX Lion says it best: the newer OpenGL specs (primarily 3.2 on up) focus better on representing what the GPU is actually doing. In OpenGL 2.1, all of the matrix operations take place on the CPU. So, not only is there no magical accelerated benefit to using GL's matrices, you are locked into a completely arbitrary model of matrix management: projection & model-view matrices only (for vertices), matrix stack size limits, a limited set of matrix operations, etc.

When you start managing your own matrices, you start to see why it is so much better. As your scenes grow more complex, you start seeing the need for more matrix caches (beyond just "projection" and "model view"). You discover opportunities to build more useful matrix functions. For instance, which sounds more pleasant to use? glRotatef(90.0f, 1.0f, 0.0f, 0.0f); or matrix.rotateX(90.0f); ? It always bothered me that I had to specify the axis of rotation every single time!

As you start to recognize the divide between CPU operations and GPU operations, you will come to appreciate managing your own matrices.

Upvotes: 3

genpfault
genpfault

Reputation: 52083

The GL-managed matrix stack is deprecated in recent revs. of the OpenGL spec. So going forward managing them yourself is the only option.

Upvotes: 1

Marcelo Cantos
Marcelo Cantos

Reputation: 185852

(As an aside, OpenGL ES 2 has no transform management facility, so in some cases you have no choice.)

More on point, I've found managing matrices via OpenGL's built-in matrix stacks to be a real pain at times, forcing me to push and pop rather copiously in the more intricate portions of my rendering code, even reordering the rendering at times just to simplify stack management. I also wrote a C++ pusher-popper class that uses RAII to automatically manage all this, but it requires careful scoping of local variables.

When I switched to ES 2, I was dismayed to learn that all that functionality was gone. However, I found that switching to my own matrices actually simplified my code, because I could work with multiple transforms using a combination of local and member variables (with meaningful names) without getting lost in space, and the transform stack was replaced mainly by using the call stack — i.e., the current transform is a just local matrix variable that gets passed as a parent transform parameter to the next function down — but with the flexibility to do it differently at other times.

Upvotes: 7

Related Questions