The Jungle Of Opengl, Where To Start?

[bzar]

I whipped up a little something:
Shader+VBO example

In my most humbly little amount of knowledge about OpenGL, I'd say this would be about the simplest example I can think of that doesn't use a fixed pipeline or immediate mode. I really know just the basics on the subject and there were many new things for me to hack together to get this working. I would like comments. Would this work with OGLES2?

Compile with:

g++ main.cpp -lglut -lGL -lGLU -lGLEW

Used tutorials and sources:

• http://sdickinson.com/wordpress/?p=122 (VBOs)
• NeHe lesson 2 (GLUT skeleton)
• Swiftless (shaders)

 

[darkblu]

In my most humbly little amount of knowledge about OpenGL, I'd say this would be about the simplest example I can think of that doesn't use a fixed pipeline or immediate mode. I really know just the basics on the subject and there were many new things for me to hack together to get this working. I would like comments. Would this work with OGLES2?

Good first attempt at it, B-ZaR. Unfortunately it's not quite fixed-function-free yet - you still use the matrix stack (glLoadIdentity, etc) and your vertex shader uses a legacy gl_* state stemming from the matrix stack (gl_ModelViewProjectionMatrix). Additionally, you use legacy vertex attributes. Those things would need to be fixed before you can be ES2-compliant.

You can check out this for an ES2 bare-bone example.

 

[bzar]

Thanks! I'll see if I can find out how to replace those with modern equivalents. This is the problem in my opinion: if anyone starts learning OGL now, most of the tutorials will be for older versions of OGL/GLSL. Without any context it's impossible to know which parts of those tutorials are admissable and which are legacy. Old- and/or misinformation makes the learning curve very steep, although the basics might actually be very simple. For a veteran it's easier as the existing domain knowlegde helps in separating the obsolete stuff from the modern code. This is also why I think it would be a good idea to get some basic level examples with guaranteed 100% modern OGL code, as it would make it easier to get through those first compatibility issues that everyone would inevitably face otherwise. No need for history lessons, better start learning the correct way from the get-go .

 

[darkblu]

I agree that figuring one's way in OLG could be an endeavor for any newcomer. OGL is an API with a long history, in a field that has evolved repeatedly, particularly lately. That said, this page should be on a quick-dial in your bookmarks ; ) You may want to check out the GLSL ES specification, chapters 7 and 8, to see what you have at your disposal in the shaders. Also, if you think you have sufficient legacy GL baggage, there is also a specification based on the differences with desktop GL, which can be very useful.

 

[bzar]

Second attempt

I removed all references to the matrix stack and replaced them with my own matrix operations and shader variables. Implemented a static camera and a trivial translation for testing. Also replaced the legacy vertex attribute with an ES2 compatible vertex pointer. Better?

Now that I've got the hang of how things are done 'round these parts, I could try to make these a bit nicer. I was thinking about a minimal example with no transformation matrices (effectively 2d), and one with functions to modify one affine transformation matrix that is sent to the shader.

Any opinion on if it's better to send the shader an affine matrix or parameters for generating one? I'd guess trigonometric operations and matrix algebra are more efficient on the GPU?

New resources:

• Joe's Blog - An intro to modern OpenGL - This is what I should have found at first. A great jump-start tutorial!
• Wikipedia - Transformation matrix - For theoretical reference
• OpenGL specs - Kinda obvious
• OpenGL ES 2.0 Quick Reference Card - This was really handy to check what I have available!

Oh, one more thing. A noteworthy snag I stepped into was that OpenGL takes matrix data as column vectors, not row. So if you define a matrix as:

GLfloat const TRANSLATION_MATRIX[16] = { 1.0f, 0.0f, 0.0f, 0.0f,
                                         0.0f, 1.0f, 0.0f, 0.0f,
                                         0.0f, 0.0f, 1.0f, 0.0f,
                                          T_X,  T_Y,  T_Z, 1.0f };

it actually means a transpose of that:

 GLfloat const TRANSLATION_MATRIX[16] = { 1.0f, 0.0f, 0.0f,  T_X,
                                          0.0f, 1.0f, 0.0f,  T_Y,
                                          0.0f, 0.0f, 1.0f,  T_Z,
                                           0.0f, 0.0f,  0.0f, 1.0f };

This is especially important to notice when using more "theoretical" or math-related sources for general information. It's actully explained very well on the Joe's blog link, but I somehow missed it at first

 

[darkblu]

that's better now. a final remark from me.

Any opinion on if it's better to send the shader an affine matrix or parameters for generating one? I'd guess trigonometric operations and matrix algebra are more efficient on the GPU?

generally no. not because it's slower per op, but it's work carried *per vertex*. like in your current vertex shader - that matrix-by-matrix multiplication you do there is done at every vertex - you need to take this out of the shader and place it into the app code.

 

[JayFoxRox]

The PVR docs recommend to upload the matrices as 3x vec4 instead of mat4 if the last row is unused (then dotp rather than multiplying matrices - check the docs for more info). (For a projection matrix you'd still want to use a mat4 though)

 

[Exophase]

generally no. not because it's slower per op, but it's work carried *per vertex*. like in your current vertex shader - that matrix-by-matrix multiplication you do there is done at every vertex - you need to take this out of the shader and place it into the app code.

If you set the parameters as uniforms and order operations properly the PVR compiler is capable of generating code that only does the matrix multiplications when you modify the uniform. See section 7.6.1 of the OGL ES 2 recommendations document:

http://www.imgtec.com/factsheets/SDK/POWERVR%20SGX.OpenGL%20ES%202.0%20Application%20Development%20Recommendations.1.1f.External.pdf

For Pandora I think it's typically better to use NEON, at least from a time spent point of view.

 

[darkblu]

If you set the parameters as uniforms and order operations properly the PVR compiler is capable of generating code that only does the matrix multiplications when you modify the uniform. See section 7.6.1 of the OGL ES 2 recommendations document:

http://www.imgtec.com/factsheets/SDK/POWERVR%20SGX.OpenGL%20ES%202.0%20Application%20Development%20Recommendations.1.1f.External.pdf

For Pandora I think it's typically better to use NEON, at least from a time spent point of view.

while i'd normally be the first to defend sane compiler tech, i'll very much advise against relying on that here. while certain cases may be fine with Imagination's compiler, they may fall flat under other GLSL compilers. generally, throwing unnecessary work at your shaders (i.e. things you can compute before the draw call) is not very portability-friendly, and as such it may (read: will) come to bite you in the ass later.

 

[Exophase]

while i'd normally be the first to defend sane compiler tech, i'll very much advise against relying on that here. while certain cases may be fine with Imagination's compiler, they may fall flat under other GLSL compilers. generally, throwing unnecessary work at your shaders (i.e. things you can compute before the draw call) is not very portability-friendly, and as such it may (read: will) come to bite you in the ass later.

Yeah I agree - if you rely on such a thing it should probably only be done where you're guaranteed to be using IMG's compiler.

 

[bzar]

Hey, thanks for all the comments and help! I think I've got the hang of things now. I'll make a couple of versions (bare bones, projection and transformations) of my program and post them here for reference for other OpenGL newbies. As I stated earlier, I'll try to stick to bare essentials and highlight new stuff. I'll try to avoid complexity because it is often counterproductive for learning. Adding complexity belongs in the area of general programming, not OpenGL. Who knows, maybe I'll write that tutorial myself as I progress .