I have been using OpenGL almost half a year, but I still do not know the essence of it. I do not understand how every OpenGL function relates to the graphics manipulation? It’s really an excruciating process to debug and correct mistakes.
Could anybody give me some suggestions how to better understand and use it?
Time is a good point for understanding things.
Reading a good book is also helpful.
You can also have a check at the OpenGL pipeline diagram (google for it) and see all the stations involved, in which order, where flow could go and so on. After you could read again about functions and see in which stage the functions operates on (vertex operation, fragment operations…) to understand when and where they are used, so that you could have a good view about how better you can use them.
Hope this helps.
Are you using the compatibility profile or core?
I ask because many details have changed in the core and it’s up to you to re- invent the wheel so to speak. However the advantage is that some aspects should make more sense.
Seconded on the pipeline diagram. Study it well, understand what parts of it each function call relates to, understand what parts happen in hardware and what parts happen in software, and understand the differences between programming to hardware and programming software.
Understanding how hardware works behind the scenes is key to getting the best out of the API.
The Common Mistakes wiki page is really really good, and you can use this as a reference for how to do certain things right as well as what not to do.
Taking an existing old-school OpenGL program and upgrading it to a more modern spec can be a neat and interesting exercise, and will be good for flexing your muscles a little.
I agree, learning OpenGL is a very slow and hard process. The documentation is very terse, usually leaving out things you have to find elsewhere.
I recommend reading: http://www.arcsynthesis.org/gltut/
Now that you have been using OpenGL for half a year, going back to this tutorial adds a lot of understanding, not just copying what others have done.
I also think that gDEBugger can be very good, except that it doesn’t work on my system.
OpenGL library design is not very good. There are a lot of side effects and interdependencies (implicit, explicit, poorly documented). That is, you change something, or the order of some calls, and your application will stop working. And then you have the (in)famous OpenGL black screen of death.
[ul][]The general advice is always change only very little, and immediately test it.[/ul] [ul][]Always use a version management system, making sure you can retrace easily.[/ul] [ul][*]Always copy working source from your own project, or someone else’s, to minimize the risk.[/ul]Another example: There was a question from someone that wanted to use the latest version of OpenGL. The counter-question was, why would you want the latest version?. Having experience with computers and programming, you quickly learn that it is usually the general answer you get to any problem report, always first update to the latest stable version. But not so with OpenGL.
OpenGL is not software, it is a spec.
It is recommended to update to the latest implementation of OpenGL, ie. update your display drivers.
For the actual spec version, like for a lot of specs, using the latest means reducing your audience.
There are a lot of side effects and interdependencies (implicit, explicit, poorly documented).
It depends on how you define “poorly documented”. The OpenGL Specification is quite explicit about everything, but it is written in “spec language,” which is useful for neither learning nor general consumption. And while there are a lot of good books on OpenGL, online material is… skimpy in quality. Oh, there are lots of places that show you what commands to use, but they rarely explain what those commands do.
One of the really nice things about working with core OpenGL is that you don’t have a lot of context state that can affect your rendering. There’s shader state, buffer object state, VAO state, FBO state, and texture state, but handling those is pretty simple; they’re all objects. That leaves blending, viewport, and a few other minor things, but you only change those when you really need it.
Fixed-function is generally where seemingly innocuous changes cause global unpleasantness. Combine this with the fact that a lot of teaching materials on the net just tell you what functions to call in what order. Very few will tell you why it should be in that order. It’s easy to find out that you should use gluPerspective after a call to glMatrixMode(GL_PROJECTION_MATRIX); an explanation of what glMatrixMode actually does is much harder to find. And looking for an explanation of why you should put the perspective call in the projection matrix and not the modelview?
Yeah, not likely.
Always use a version management system, making sure you can retrace easily.
Yeah, but who doesn’t use a version control system? I mean, why would you develop without one? It’s so nice being able to commit to a private Mercurial repository, as well as look back in your history and see what you’ve done, where you broke things, etc.
Always copy working source from your own project, or someone else’s, to minimize the risk.
Um, no. If you ever hear someone give this advice, feel free to smack them in the face.
Copy-and-paste coding should never be encouraged. Doubly so when learning.
The counter-question was, why would you want the latest version?
That’s crazy. Why wouldn’t you want to use the latest version of Direct3D? I mean, it’s the highest number, right? That must mean it’s the best.
Oh, that’s right: Direct3D versions correlate to hardware. So if I make a D3D11 application, only people with D3D11 hardware can run it. Whereas if I make a D3D10 application, people with 10 and 11-class hardware can run it. That way, instead of selling to maybe 10% of the buying public, I can sell to 50+%.
Do you get the point?
Do you know that this particular API is being developed by the consortium? If something is firmly stood for dozen of years and operates on immense number of platforms, I wouldn’t dare to say it is not good.
Is this an announcement for Windows 8? 
(Explanation for those with cheaper tickets: Blue screen of death in former Windows is now replaced with Black screen of death.)
The answer is obvious: to access new functionality, and get some bugs in the previous release of drivers fixed. Of course, there can be new bugs, but you can always return to previous “stable” release if you are not satisfied with the current.
If something is firmly stood for dozen of years and operates on immense number of platforms, I wouldn’t dare to say it is not good.
I would. Just because you have something that people have used for a long time doesn’t mean that it’s good.
OK! It’s your right to freely express your opinion. 
But since you are using OpenGL, and further more you have become an OpenGL guru, it suggests that you don’t have a bad opinion about the API. 
The OpenGL Specification is quite explicit about everything, but it is written in “spec language,” which is useful for neither learning nor general consumption. And while there are a lot of good books on OpenGL, online material is… skimpy in quality.
I agree with that. I am not a professional, I am hobbyist. And that is something that is really jarating me off.
I think one way to promote OpenGL to a wider audience would a better online manual from OpenGL itself.
Especially here in Germany where I actually live it is very hard to find a good OpenGL Books in my language. Esp. for OpenGL 3+. Mostly they are for universities, not very easy to read and OpenGL 2.x.
I can read english books though, but the learning curve is steeper when you read things not in your language when you have to translate it while you read it. That takes some portion of your concentration away.
It is the same in France, and in Italia, and in Spain, and in Russia…
If you read a scientist paper, it will be written in english. If you make a paper, it will be in english. Everything “high enough” is made in english. This is the language for science stuffs.
And really, I prefer to read a book in english now than the same book but poorly translated by french people whose job is to translate book but who has absolutely no knowledge about computer science, or so few that it takes more long time to understand what is meant in my natural language than in english. I’ll never read a novel in english so far, but if it’s about computers, now I strongly avoid french books, or translated books.
To finish, my first books where in french. But quickly I moved to english books because it is, and not a few, far better. Of course it is difficult, but when you program, you program in english, when you look at a library doc, most of the time it is in english too… So at the end, it’s all good for you, even if it could take more time, even if you could misunderstand some points
And so we have users who ask why doesn’t my object not get textured or something like that. They show their code
glBindTexture(…);
glDraw(…);
glUseProgram(…);
glClear(…);
glFlush();
glFinish();
glutSwapBuffers(…);
and I have to say…WTF?
Some people just seem to throw lines of code together and don’t understand why it doesn’t work, despite the fact that they have access to the biggest source of information that has ever been created.
I wonder if they are university students just trying to get a passing mark.
LOL
Not to beat a dead horse, but I felt I had to pipe in on one thing.
Remember: in medieval Europe “medicine” for quite a number of years meant someone who was sick was drained of mass amounts of their blood to get the “toxin” out. Anyone looking at that today would be appalled by such a treatment.
Not saying that’s exactly going to apply to this thread, but I just felt I had to throw that one in there.
I don’t think this comparison is applicable to what I said.
Can someone tell me why OpenGL is so widely spread if it is not a good API? Being an open standard is certainly important, but is it enough for such popularity?
I suspect that it very probably is. Something (and it could be anything) that’s quite mediocre could very easily eclipse a superior solution simply by virtue of being more widely available.
(Note: I’m not doing API comparisons here, I’m talking in general.)
True enough, some parts of OpenGL’s design are quite clunky nowadays (witness the howls of despair that accompanied the original 3.0 spec if you need proof of that), and it’s questionable whether the requirement to provide software fallback for anything that’s not hardware accelerated was a good decision for all cases.
Can someone tell me why OpenGL is so widely spread if it is not a good API? Being an open standard is certainly important, but is it enough for such popularity?
Because it’s all there is. If you want to do cross-platform development, it’s your only choice.
Oh, someone could come along with a new API. And maybe they could get, say, Apple to implement it. But will they get it implemented on Linux? Windows? No.
The simple fact is that, in many cases, the first thing that works is what people use. Not the best thing, not even a good thing, just the first thing that comes along that happens to work.
People will put up with crap if it allows them to do what they need to do and there are no other alternatives. People actually wrote code in Direct3D version 3.0. Look the API up; it’ll make your eyes bleed.
But if you want a very simple example of the “not good” parts of OpenGL’s API, here’s a quick example:
glUniform1i(program, samplerLocation, texUnit);
glActiveTexture(GL_TEXTURE0 + texUnit);
glBindTexture(GL_TEXTURE_2D, textureObject);
glBindSampler(texUnit, samplerObject);
Just look at what is necessary to bind a texture to a texture unit and compare it to a sampler object. You have to set the active texture. But not to the texture unit itself; no, you have to set it to “GL_TEXTURE0” plus the texture unit. Why? Hey, don’t look at me, it’s OpenGL’s cruft.
After setting the active texture unit, only then can you actually bind the texture. But glBindTexture also specifies the type of texture. Why? It is illegal to bind that texture as anything other than its original texture type. So what’s the point of having to remember and explicitly say “GL_TEXTURE_2D” if OpenGL already knows that?
Sampler objects, a much more recent API, work exactly like what you expect. The bind call includes the texture unit. Not an enum, but the texture unit itself.
Next, there’s the use of GLSL samplers as “uniforms,” even though they have virtually none of the traits of uniforms. They can’t be in uniform blocks or structs. Even if they’re in arrays, you have very restricted access to those arrays. And so forth.
Compare this to uniform blocks. Uniform blocks aren’t uniforms; they’re a completely different kind of thing. Just like samplers should have been.
And this doesn’t even get into other boneheaded API decisions, like linking shaders into a single monolithic program (pre-separate_program_objects, which has some spec issues itself).
I know that people are willing to accept “good enough” instead of “best” if learning all the alternatives might cost time or effort.
The term “satisficing” (as a combination of “satisfying” and “sufficing”) was devised in 1957 by the social scientist Herbert Simon, who used it to describe the behavior of people in all kinds of economic and social situations.
Several days ago you wrote a nice post about texture units, and now you are saying this. There is nothing odd in the binding texture procedure. I know that I don’t have to teach you why it is so, but I have an obligation for the sake of newbies to clarify some facts:
Each texturing unit has several “current” textures: 1D, 2D, 3D and cube map. By setting GL_TEXTURE_2D you actually specify that you are changing current 2D texture.
Texture units are numbered form 0 to GL_MAX_TEXTURE_UNITS-1, but enumeration starts from 0x84C0 (i.e. GL_TEXTURE0). Why it is so I don’t know, but I don’t find it is a problem.
glBindSampler() is also the part of OpenGL API. It is the “new API”, as you’ve said, and it seems that you like it. So, OpenGL is going to the right direction.
The property I like best in OpenGL is the ability to use new functionality as soon as it is implemented in drivers. You just need to know signatures of the functions and what they are doing. Of course, the problem is that different vendors can have different implementations. Something that is available on one implementation doesn’t have to be available on the other. That’s why the major functionality has to be promoted to the core and became an obligation for vendors to implement. Other exotic stuff is for enthusiasts and researchers.