PDA

View Full Version : How to better use OpenGL



shapeare
07-06-2011, 06:08 AM
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?

_arts_
07-06-2011, 06:40 AM
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.

BionicBytes
07-06-2011, 06:47 AM
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.

mhagain
07-06-2011, 10:00 AM
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 (http://www.opengl.org/wiki/Common_Mistakes) 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.

Kopelrativ
07-06-2011, 01:55 PM
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 (http://www.gremedy.com/) can be very good, except that it doesn't work on my system.

Kopelrativ
07-06-2011, 10:27 PM
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.
The general advice is always change only very little, and immediately test it. Always use a version management system, making sure you can retrace easily. Always copy working source from your own project, or someone else's, to minimize the risk.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.

ZbuffeR
07-06-2011, 11:08 PM
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.

Alfonse Reinheart
07-07-2011, 12:25 AM
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?

Aleksandar
07-07-2011, 01:06 AM
OpenGL library design is not very good.
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.


And then you have the (in)famous OpenGL black screen of death.
Is this an announcement for Windows 8? :D
(Explanation for those with cheaper tickets: Blue screen of death in former Windows is now replaced with Black screen of death.)


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?.
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.

Alfonse Reinheart
07-07-2011, 01:17 AM
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.

Aleksandar
07-07-2011, 02:16 AM
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. ;)

_ShaderRookie_
07-08-2011, 05:43 AM
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.

_arts_
07-08-2011, 06:33 AM
Especially here in Germany <...> for universities <...>

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 :)

V-man
07-08-2011, 07:08 AM
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.

BionicBytes
07-08-2011, 08:01 AM
LOL

OmegaDeus
07-08-2011, 08:37 AM
Not to beat a dead horse, but I felt I had to pipe in on one thing.



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.

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.

Aleksandar
07-08-2011, 09:02 AM
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.
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?

mhagain
07-08-2011, 12:53 PM
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.

Alfonse Reinheart
07-08-2011, 01:10 PM
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).

Aleksandar
07-08-2011, 06:02 PM
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.


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?

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:

1. 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.

2. 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.

3. 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.

Alfonse Reinheart
07-08-2011, 06:48 PM
1. 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.

And what purpose does that serve? Can you bind two textures, one to 1D and one to 2D, to the same texture unit and then set two samplers in the shader to use the same texture unit?

No. That will cause a rendering error. So why allow it at all?

Because that's how OpenGL always worked. It's legacy cruft from back in the OpenGL 1.0 days; it makes absolutely no sense in the modern world, but thanks to the ARB's design goals of minimal change (ie: each new feature should use existing APIs as much as possible, and require the least possible user change to access), that's what we have.


Why it is so I don't know, but I don't find it is a problem.

That's because you already know how it works. The problem is when you have to explain it to someone. This API doesn't make intuitive sense, and therefore explaining it requires several paragraphs of explanation when a single paragraph would do. For example, in my recent tutorial on texturing, I wrote this:


The glActiveTexture function changes the current texture unit. All subsequent texture operations, whether glBindTexture, glTexImage, glTexParameter, etc, affect the texture bound to the current texture unit. To put it another way, with UBOs, it was possible to bind a buffer object to GL_UNIFORM_BUFFER without overwriting any of the uniform buffer binding points. This is possible because there are two functions for buffer object binding: glBindBuffer which binds only to the target, and glBindBufferRange which binds to the target and an indexed location.

Texture units do not have this. There is one binding function, glBindTexture. And it always binds to whatever texture unit happens to be current. Namely, the one set by the last call to glActiveTexture.

What this means is that if you want to modify a texture, you must overwrite a texture unit that may already be bound. This is usually not a huge problem, because you rarely modify textures in the same area of code used to render. But you should be aware of this API oddity.

Also note the peculiar glActiveTexture syntax for specifying the image unit: GL_TEXTURE0 + g_gaussTexUnit. This is the correct way to specify which texture unit, because glActiveTexture is defined in terms of an enumerator rather than integer texture image units.

At that point in the tutorial, I had already explained the concept of texture units. So why did I need 5 paragraphs to explain how to bind to them?

Because the API is not intuitive. And that ignores the paragraph earlier spent talking (and warning) about binding textures to different targets. Indeed, I could add another paragraph or two talking about the interaction between texture targets and image units, but that would have been confusing.

By all rights, the API should be:


glBindTexture(texUnit, textureObject);

Once you understand the concept of a texture unit, this function should require no more than one paragraph of explanation, if that much.

You tell me: which is easier to understand for a neophyte user?


So, OpenGL is going to the right direction.

You can't go in the right direction if half your API looks stupid. That just makes your API inconsistent on top of not making sense.


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.

That is completely orthogonal to API cleanliness. You can have a clean API and an extension mechanism too.

OmegaDeus
07-08-2011, 09:13 PM
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.

I couldn't agree more, look at Windows and DirectX. I mean neither of them are very good, but they dominate the market because they take away much of the thought process from people. I mean Direct3D has built in functions to read .x formatted files. No need to write your own model loaders when you can let the SDK do it for you.

And in reference to Windows, remember the ME debaucle. I mean they were rushing to produce a "millenium edition" that the computer I purchased which came with it (first one i ever bought new mind you), never booted out of the box even after I did a fresh wipe of the system and installed the OS from a CD and had no programs added. But still many people used ME and some even liked it. But Windows was more widespread so it stuck around. On another note though, that's when I discovered the wonderful world of Linux.

V-man
07-10-2011, 05:36 PM
I'm surprised they still have kept glBindTexture in GL 4.1.


I couldn't agree more, look at Windows and DirectX. I mean neither of them are very good
I would have to disagree. Windows is used and abused by an immense amount of users. The graphics drivers are highly tuned (by their respective designers) with zillions of man-hours invested in them.


I mean Direct3D has built in functions to read .x formatted files. No need to write your own model loaders when you can let the SDK do it for you.
Professionals don't care for the .x file format. That's for students at your local college or university making their first project.

They care about the debugging tools. They care about the IDE (Visual Studio). They wanna know if they have a resource leak or corruption.

mhagain
07-11-2011, 01:26 PM
I couldn't agree more, look at Windows and DirectX. I mean neither of them are very good, but they dominate the market because they take away much of the thought process from people.

Hmmm, I get the sense that it's been a good while since you've last looked at Direct3D. You may not be aware that since at least version 8 D3D has been in many ways a much cleaner API than OpenGL (needing much less code in many places too), with legacy cruft cast away and much more sensible ways of doing things (that map more closely to how graphics hardware actually works) brought to the fore.

In fact your point about taking away thought processes applies a lot to OpenGL. Take immediate mode for example. It's really really easy to get some simple (and simplistic) rendering up and running using immediate mode, but as soon as you start going down that route you're putting yourself in a position where you're (a) not getting anywhere near the best out of your graphics hardware, and (b) essentially going to have to learn everything all over again (as well as undo a lot of bad habits) if you want to do things the right way.

This kind of accessibility is both OpenGL's strength and it's weakness. It's a strength because it can get lots of simple (and simplistic) programs without too much investment required. It's a weakness because it complicates the API (by needing to support the wrong way as well as the right way) and leads to an awful lot of really bad programs (and tutorials, unfortunately) being written by people who really don't know what they're doing.

Kopelrativ
07-12-2011, 12:13 AM
Take immediate mode for example. It's really really easy to get some simple (and simplistic) rendering up and running using immediate mode, but as soon as you start going down that route you're putting yourself in a position where you're (a) not getting anywhere near the best out of your graphics hardware, and (b) essentially going to have to learn everything all over again (as well as undo a lot of bad habits) if you want to do things the right way.

This kind of accessibility is both OpenGL's strength and it's weakness. It's a strength because it can get lots of simple (and simplistic) programs without too much investment required. It's a weakness because it complicates the API (by needing to support the wrong way as well as the right way) and leads to an awful lot of really bad programs (and tutorials, unfortunately) being written by people who really don't know what they're doing.

I agree on this. Unfortunately, Internet can easily fool you here. If you are a beginner, there is a lot of information and tutorials about the immediate mode. But not so much information about the shader way. These old tutorials usually never mention anything about the deprecated nature of the legacy code.

I think there is a high risk that many beginners falls into just the trap you mention.

On the other hand, learning OpenGL (if you come from "nowhere" in respect of modern graphics) is a steep curve. Going through the immediate mode actually helps you understand some basics first. Even if the source code may have to be replaced, the knowledge can be reused. In this case, I refer to understanding for vertices, matrices, textures, colors, etc.