8
\$\begingroup\$

Which is more efficient using OpenGL's transformation stack or applying the transformations by hand.

I've often heard that you should minimize the number of state transitions in your graphics pipeline. Pushing and popping translation matrices seem like a big change. However, I wonder if the graphics card might be able to more than make up for pipeline hiccup by using its parallel execution hardware to bulk multiply the vertices.

My specific case. I have font rendered to a sprite sheet. The coordinates of each character or a string are calculated and added to a vertex buffer. Now I need to move that string. Would it be better to iterate through the vertex buffer and adjust each of the vertices by hand or temporarily push a new translation matrix?

Improve this question
\$\endgroup\$
1
  • \$\begingroup\$ Depends which GL version you are targeting. They are deprecated in 3.x and onwards. \$\endgroup\$
    – PrettyPrincessKitty FS
    Jan 13, 2011 at 18:38

5 Answers 5

Reset to default
7
\$\begingroup\$

It's my understanding that in the most recent versions of the spec (3.3 and 4.x) the matrix stacks are gone and you need to keep track of your transformation matrices by hand. I believe this might be true for the mobile (ES) spec as well.

If you're looking for a consistent way to handle your matrices by hand, you might be interested in GLM. It's a pretty neat math library (which includes matrix transformations) modeled after the GLSL spec so you only need to keep one set of math routines in your head when dealing with OpenGL code.

Improve this answer
\$\endgroup\$
4
  • \$\begingroup\$ Can anyone confirm this? I learned graphics programming with OpenGL 1.5 and thought I was advanced because I was experimenting with some of the 2.0 features. You might say I'm a bit out of the loop. Dropping support for translation matricies seems to be a huge disadvantage. \$\endgroup\$
    – deft_code
    Jan 13, 2011 at 6:15
  • 1
    \$\begingroup\$ Just double checked. Yes, the matrix stacks are deprecated in 3.0 - 3.2, and removed in 3.3 and 4.x. The idea is that since the whole pipeline has gone programmable you'll just pass your final matrix in to your shader and go from there. There's nothing to stop you from sticking with OpenGL 2.0, though. All the matrix stack functionality you're used to will still be there. \$\endgroup\$
    – Bob Somers
    Jan 13, 2011 at 6:19
  • \$\begingroup\$ Note that that does not mean "support for translation matrices" was dropped, @deft_code. A translation matrix is just a particular set of floating point values after all, you can trivially build one yourself. It's more in the area of "linear algebra" than access to the graphics pipeline, really -- note that D3D doesn't have analogous functions either (they're in a separate utility library, D3DX). \$\endgroup\$
    – user1430
    Jan 13, 2011 at 7:25
  • 1
    \$\begingroup\$ Slight addition: GLES 1.x is the fixed functionality analogue of OpenGL 1.5 (ish) and includes the texture, modelview and projection stacks. GLES 2.x is the fully programmable embedded OpenGL and does not include the matrix operations at all, or any of the rest of the fixed functionality pipeline. So in GLSL there's also no gl_Vertex/Normal/Color/etc. How you pass information into a shader program is entirely up to you. \$\endgroup\$
    – Tommy
    Jan 13, 2011 at 13:41
3
\$\begingroup\$

The stack is the less-optimal option here -- not because pushing and popping it was expensive, as it should not ever induce a complex driver-level state change (the matrix shouldn't be sent to the card until a render command is issued, so it's all CPU-side manipulation in the API, usually).

The problem with the stack is that it has a limit to how far you can push it -- it's one of the parameters you could get at via glGet* I think. There's no big advantage to using the stack unless you don't have or are incapable/do not desire to write matrix math. I would recommend doing it yourself.

I don't know what the state of the stack functions are in modern GL. I believe they've been deprecated/removed as well, but I haven't had the need to actually use GL in a while so I have not kept as up to date.

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

As others have noted, the matrix stack is on its way out, which is a good reason to investigate alternatives.

On one of my projects, I used the OpenGL's matrix ops to calculate my matrices, but ended up having to use glGet functions to fetch the matrix back so I could do some operations on the matrix that OpenGL's own functions didn't support. The performance was abysmal, and I traced the loss to the single glGet function. It's possible that the matrix ops are actually performed on the GPU somehow, and using glGet caused pipeline flush, or something.

Whatever the reason, I replaced the matrix operations with CML, the configurable math library, and the performance improved dramatically. Not only was I no longer bound to the performance metrics of the OpenGL matrix operations, CML also included tons of operations OpenGL doesn't support.

And implementing a stack of matrices is pretty easy using STL vector or some such.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

I'm not sure of your level of experience, but I would recommend doing it by hand. It may take more effort to learn how to do this, but it is immensely beneficial to know what your matrices are doing and to be able to manipulate them yourself. It will also make you more aware of issues that may crop up when applying matrices in different orders (eg. scaling then rotating). I know I spent many hours trying to figure out weird render "bugs" before deciding my time would be better spent thoroughly studying what each operation was doing. It's worth the investment.

Addressing your specific issue, applying a transform to the vertices seems like the easiest way, just be aware of the order of operations of matrices.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

The main problem that I see is that you need to access the results for other game tasks and acessing those results can be complicated and slow.

Thats why I prefer to do those matrix operations myself.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .