Great OpenGL 3.1 tutorial

Gah.

Do we not know how to teach? The code is only incidental, for it will vary from language to language, and some aspects will vary from operating system to operating system - OpenGL is highly portable and has bindings to virtually every programming language. The code-dump-and-comments style of "tutorial" does little to give people a deep understanding of the principles at work here. I mean, compare it - and, yes, NeHe - to the red book, which spends a considerable amount of time discussing concepts and explaining how OpenGL approaches various representations.

But people want quick results, something they can copy and compile and see blobs on the screen to give them a false sense of accomplishment. If you don't understand what you've done, what have you accomplished?

It's a terrible tutorial. It's a decent code snippet.

I would not consider it terrible. It says at the top "if you already have experience with GL 2.1". Someone with background would know what he needs to do to bring that code into his Pascal, C#, java, ADA, or whatever.

I do not understand such a reaction from the staff. OpenGL IS a cross-platform API. There is no doubt! But, currently, there is no working code sample using OpenGL 3.1 on the whole bloody Internet. Or, maybe, I don't know how to use search engines? (Forget about OpenGL 3.x rendering context creation. Such tutorials do exist, but what to do with the context later?)

The first triangle on the screen, gained with no deprecated functions was a revelation for me. So far, there is only one book deal with OpenGL 3.x code. It is "Beginning OpenGL Game Programming 2nd Ed". I do not posses that book, but I hope that it is worth having. The "Red book 7th Ed." will be published in September. I also agree that it is a great resource (I have two revisions of OpenGL Programming Guide in my personal library), but do we have to wait until then.

Well, I agree that mentioned tutorial is not complete, not cross-platform, and maybe, not good at all, but... Too many people are searching for any OpenGL 3.x code. It is a crime not to help them. Any suggestion and any snippet of code can be helpful. I'll give my best!

P.S. I have only to criticize gvizbi for the title. It is not a great tutorial, but just the beginning of something that could help. [cool]

[Edited by - Aks9 on July 11, 2009 3:42:34 AM]

Maybe I exaggerated a little bit that it is great, mainly because there were NO tutorials on Internet for OpenGL 3.1 until this one and I was excited. Actually, it's not only that there are no tutorials, articles concerning OpenGL 3.1 generally are very scarce. But I surely think that this is very nice and useful tutorial.

@Oluseyi:
Why do you think that tutorial is good only if it's written for every language, for every OS existing and that every aspect have to be covered. If someone is programming in MS Visual C++ on Windows platform and is considered expert in that area, it's natural that he should write tutorial for MS Visual C++ on Windows. This is also a great oportunity for you, me or any other member of gamedev.net to cover all other aspects, languages, OS that are not covered in this tutorial. After all, we are comunity and we should write and explore new techologies together.

That's not really what Oluseyi is saying; a good tutorial doesn't dump code on you with some comments. A good tutorial teaches you how things work so that you can learn something and build upon it.

A comment in this thread is very telling of the problem with 99% of tutorials.

Quote:

I would not consider it terrible. It says at the top "if you already have experience with GL 2.1". Someone with background would know what he needs to do to bring that code into his Pascal, C#, java, ADA, or whatever.

If you have experience with GL2.1 and understand what you are doing then getting up and running with GL3.x shouldn't be any harder than looking at the bits of the spec you need and making the changes as such a 'tutorial' such as this is nothing more than a short cut for writing your own code.

If you have no experience and want to learn how to do things in OpenGL 3.x from scratch then this "tutorial" is no good because it doesn't explain whats going on, it simply shows and people WILL copy from that. These people then fail to learn and chances are they will go on to fail to learn, always looking for short cuts and code they can copy to get places.

The end result is what you see around gd.net too often; people who have done things but have no idea how they have done them.

This is not teaching; this is monkey see, monkey do and is very little use to anyone.

There is nothing wrong with code as such, but it should serve as a means to demostrate that which has been explained.

Quote:

If you have experience with GL2.1 and understand what you are doing then getting up and running with GL3.x shouldn't be any harder than looking at the bits of the spec you need and making the changes as such a 'tutorial' such as this is nothing more than a short cut for writing your own code.

I strongly disagree that reading the specification is enough to get your application up and running. OpenGL 3.x is significantly different than previous versions. I have read the specification, but I got the idea how it works when I started to write a code. It isn’t so simple. I will not elaborate the problems that I had with transition to new API, although I have many years of experience in OpenGL programming.

I'm involved in teaching computer graphics (and OpenGL) on the Faculty of Electronic Engineering for more than five years, and I very well know what the problems in teachings are. Practice without theory is dangerous! But my intention was not to write a comprehensive text about OpenGL 3.x. Take a look around. Thousands of programmers around the world are searching for OpenGL 3.x tutorials. It is selfish no to get them something to start with.

OpenGL 3.0 specification was late. Direct 3D is not a competitor now. OpenGL is! After more than 10 years or struggle, Microsoft has the most prosperous API. By throttling such "code dumping" on the sites, we will loose "new followers of OpenGL programming".

Apropos multiplatform support, my next step is to make a side-by-side overview about working with vertex arrays and vertex buffer objects in:
- OpenGL 2.x using fixed functionality,
- OpenGL 2.x using shaders,
- OpenGL ES 2.0 and
- OpenGL 3.x.

I'll be glad if you give me a suggestion how to entitle it, because "a tutorial" is obviously very undesirable term.

Quote:

Original post by Aks9 I will not elaborate the problems that I had with transition to new API

I think it would be benefical if you elaborate. It's the practical things that matter.

Quote:

Original post by Aks9 I strongly disagree that reading the specification is enough to get your application up and running. OpenGL 3.x is significantly different than previous versions.

The spec should be plenty, as long as you have been adopting current OpenGL practices along the way. If all of your GL 2.x code is exclusively using VBO, FBO and modern shaders (i.e. not using built-in attributes, uniforms or varyings), then the transition to 3.0 is almost seamless.

Quote:

I'll be glad if you give me a suggestion how to entitle it, because "a tutorial" is obviously very undesirable term.

Tutorial is a perfectly good name for it, provided it is a tutorial, and not just a giant, commented code-dump.

GL 3.x is not really that different from old GL but having an example to how to create something as simple as a context is important. The spec WGL_ARB_create_context at www.opengl.org/registry doesn't have an example.
This is often the case. Those extension specs are just ugly plain text and although reading them is important, sometimes I don't know what to do and need an example.

It's the same thing with the GL spec. It is just a huge pdf file and doing searches in it is difficult. Example : if I want to search for GL_TEXTURE_2D, it doesn't find anything. I have to change that to GL TEXTURE 2D.

Finally, they created this http://www.opengl.org/sdk/docs/man/

but again it sucks because it convers old junk. I had to create the wiki to give really detailed, real world, sometimes GPU specific information
http://www.opengl.org/wiki

BTW, the Wiki explains the process of making a GL 3 context
http://www.opengl.org/wiki/OpenGL_3.0_and_beyond%2C_creating_a_context

Quote:

Original post by Aks9 OpenGL 3.x is significantly different than previous versions.

There will now be a 20min break while I finish laughing about this statement.

OpenGL3.x is nothing more than an incremental update over GL2.x, the API has remained largely untouched the biggest changes are the "lack" of FFP functionality. (I say "lack" because with an extension all the FFP stuff is back anyway! yay! [rolleyes]).

I had a proper look over the code in that tutorial and honestly, there is nothing new there when setting up a context; you had to use wglCreateContextAttribsARB() before now if you wanted a context with AA anyway, this nothing new.

The only thing which is new is saying what version you want and if you want it to be forward compatible or not.

Quote:

I'm involved in teaching computer graphics (and OpenGL) on the Faculty of Electronic Engineering for more than five years, and I very well know what the problems in teachings are. Practice without theory is dangerous! But my intention was not to write a comprehensive text about OpenGL 3.x. Take a look around. Thousands of programmers around the world are searching for OpenGL 3.x tutorials. It is selfish no to get them something to start with.

Ah, so the answer to 'alot of people want to know how to do things' is to dump the information on them instead of teaching them... right, right, good solution.

Quote:

OpenGL 3.0 specification was late. Direct 3D is not a competitor now. OpenGL is! After more than 10 years or struggle, Microsoft has the most prosperous API. By throttling such "code dumping" on the sites, we will loose "new followers of OpenGL programming".

To be fair, even if the OpenGL 3.0 spec has been 'on time' it wouldn't have mattered; the API is out and outdated in it's current form. Longs Peak would have fixed this but the ARB dropped the ball AGAIN.

Frankly, and I speak as the ex-mod for this forum section and the writer of two FBO articles and the GLSL section of More OpenGL Game Programming, unless you have to use OpenGL these days D3D is the way you should be going. It was marginal at best when D3D9 came out between the two, D3D10 is a MUCH nicer API and D3D11 goes further and allows you to do things easily and sanely in a multi-threaded world which is the future.. the ARB however still seems to be stuck in a single threaded existance. *shrugs*

The reason you will lose "new followers of OpenGL programming" is the poor API, not the lack of [poor] examples.

Quote:

- OpenGL 2.x using fixed functionality, - OpenGL 2.x using shaders, - OpenGL ES 2.0 and - OpenGL 3.x.

I'd forget GL2.x completely, there is no future there and GL3.x in pure mode is at least a slight step up from what was had before.

The KEY point is not to dump code with some comments, it's to teach concepts to explain things and use the code to support where needs be. The code should NOT be the main part of the text, you say you work in education so you should know this stuff.

Quote:

Original post by phantomThe code should NOT be the main part of the text, you say you work in education so you should know this stuff.

You should see the way programming courses at school work over here. Everytime I get a glimpse I have to wonder how those people can dare to call themself a teacher. There might be some decent ones, but far too many courses seem to work like this:

-dump code for a specific task on students
-if you're having a good day, explain what each line does
-write a test, which is a 99% carbon copy of a presented task
-see if they can correctly adjust the parameters of the function call

It's more about memorizing a receipe than understanding what you're doing. In fact, when I attempted giving private lessons to someone I knew, I was kind of shocked to see how they were "tought" Delphi in their second year and never heard words like "class" or "object" before and still accepted syntax like a.b.c() as "just how it is".

A touch off-topic, but I think it is worthwhile to elaborate on this thread to the following as the thread topic will attract people new to programming in 3D graphics:

Phantom, you have really gone to hating OpenGL very, very harshly so badly on the PC platform. Not to be nasty, exactly what features of D3D10 are not in GL? If you say "geometry shaders", they are exposed as an extension and I too am disappointed that they were not made to core, but it was only missing feature of the GL3 that pissed me off; even now there are some, atleast to me, exciting extensions (yes I know extensions not core) coming from nVidia: bindless graphics, that has potential to do some really neat things which AFAIK cannot be done in D3D as directly or as easily, also ATI/AMD has released a tessellation extension too, which is available NOW on their hardware. As for D3D11's multi threading capability, as far as I have seen it, and correct me if I am wrong, it looks more like a nice delegate system; it is nice that it is part of the API, but not exactly brain surgery to write one's own delegate system. Additionally, there are a lot of consumers that do not have Vista, which D3D10 and 11 require, where as GL 3.x is available now on XP (and for the academics, Linux). What part of the GL API has so many people knickers in a twist (aside from the bind to edit textures and buffer objects)? {I would have also liked separation of texture data and filtering and the ability to sample from the stencil component of a depth-stencil texture} Asking for precision, what parts of the GL 3.x API are, in your words, outdated?


Also, for portable devices, you will be writing against GLES 1 or 2, strictly speaking they are different API's but they are more or less GL 1.x and 2.x (respectively) with GLES2 removing fixed function pipeline, fewer texture formats required, and FBO in core. The portable arena prolly has the most room for smaller developers, and there it is, more or less for 3D graphics, GLES or bust.

I also want to defend Aks9 a touch when he said that GL 3.1 is significantly different that GL 2.x, when doing teaching the usage is very, very different. Often for teaching 3D graphics one starts with the fixed function pipeline as an example of how to do rasterization graphics: per-vertex lighting, texture-co-ordinates, projection and modelview matrices. When _learning_ 3D graphics the FFP is an excellent learning tool to ease a new comer into 3D graphics. As a student advances they will slowly stop using the FFP, but to ask a new comer to start point blank with shaders is awfully rough, where as starting with the FFP an instructor can have students concentrate in certain areas without needing to know all the grimy details. Once the students have grown where they are comfortable with projections, 3D transformations, texturing, projective and non-projective interpolation, simple lighting models, clipping, texture filtering, etc., then going onto the land of no FFP is good, which we do in our applications, but because we already know those concepts so solidly we do not need an API to hold our hands through it. Once one is using shaders exclusively, then the move from GL 2.x to 3.x is often a no-op. It is the act of using exclusively shaders that can take work, especially if one has implemented a GUI in GL (this is most likely why most CAD applications want FFP so badly I imagine).

Also, the idea of log peaks lives on in forward compatible contexts (where if you ask for such a context, then the FFP compatibility extension GL_ARB_compatibility will not be present). I think that you were so horribly disappointed by the fact that GL3 did not have the avoiding bind to edit API and it was a year late... but GL3 did add a great deal which was useful (and you can argue that much of that was already in D3D10 much time before) but it had a great deal that was very, very useful (admittedly almost all were exposed as extensions before): texture integers, mixed FBO formats, integers in shaders, transform feedback and 3.1 added texture buffer objects, uniform buffer objects, instancing, primitive restarting and more. Yes, all of it was already in D3D10 and GL is catching up to D3D, but I think we will see that gap close more in the next 18 months. Myself, I am very excited by [link] http://developer.download.nvidia.com/opengl/specs/GL_NV_shader_buffer_load.txt [/link].

[Edited by - kRogue on July 14, 2009 7:29:37 AM]

Quote:

Original post by kRogue I also want to defend Aks9 a touch when he said that GL 3.1 is significantly different that GL 2.x, when doing teaching the usage is very, very different. Often for teaching 3D graphics one starts with the fixed function pipeline as an example of how to do rasterization graphics: per-vertex lighting, texture-co-ordinates, projection and modelview matrices. When _learning_ 3D graphics the FFP is an excellent learning tool to ease a new comer into 3D graphics. As a student advances they will slowly stop using the FFP, but to ask a new comer to start point blank with shaders is awfully rough, where as starting with the FFP an instructor can have students concentrate in certain areas without needing to know all the grimy details. Once the students have grown where they are comfortable with projections, 3D transformations, texturing, projective and non-projective interpolation, simple lighting models, clipping, texture filtering, etc., then going onto the land of no FFP is good, which we do in our applications, but because we already know those concepts so solidly we do not need an API to hold our hands through it. Once one is using shaders exclusively, then the move from GL 2.x to 3.x is often a no-op. It is the act of using exclusively shaders that can take work, especially if one has implemented a GUI in GL (this is most likely why most CAD applications want FFP so badly I imagine).

I agree that fixed function the way it's implemented in GL is invaluable for teaching, however i am not sure it should be part of the spec. If i look at introductory programming courses, nearly every of them use some own high-level function library to protect the newcomers from harshness of the language in question, and i think it should be the same way with opengl. It's simple to implement (subset of) the GL base as a library which internally uses shaders, or better, create whole new system based on OO design, eliminating all the historic cruft that had piled up in OpenGL.

Quote:

Original post by kRogue Phantom, you have really gone to hating OpenGL very, very harshly so badly on the PC platform. Not to be nasty, exactly what features of D3D10 are not in GL? If you say "geometry shaders",........etc

I am not Phantom, but I don't see why GL can't be made simple and have features on time. Remember the p-buffer situation? Remember NV_register_combiner vs whatever ATI had? Remember how ARB_vertex_program and ARB_fragment_program weren't getting updated? Remember how GL 2.0 was suppose to be this fresh new API and the same thing repeated again with GL 3.0?
Now there is this backwards and forward compatible context thing. Why create such confusion?
D3D10 doesn't have any backwards crap. It is what it is and no one is against it.

Frankly, D3D would make a better cross-platform API. There isn't any GLX, wgl, AGL, egl and tons of extensions.

Quote:

Original post by V-man D3D10 doesn't have any backwards crap. It is what it is and no one is against it.

This made me laugh :)
I think you will find most developers completely skipped DX10, impart due to crappy Vista and it not being worthwhile supporting it. Lets not turn this into another DX v's GL thread.

Going back to the tutorial briefly, I just wanted to check that my understanding of VAOs was correct. I was under the impression that you only called glVertexAttribPointer once when you setup the VAO (or maybe again if the data changed) and not every time that you render your scene like the tutorial shows. In fact, I thought that was the main reason for them. I haven't implemented VAO yet and I just wanted to make sure I had it straight in my mind before I do.

Quote:

Original post by Trienco You should see the way programming courses at school work over here. Everytime I get a glimpse I have to wonder how those people can dare to call themself a teacher. There might be some decent ones, but far too many courses seem to work like this: -dump code for a specific task on students -if you're having a good day, explain what each line does -write a test, which is a 99% carbon copy of a presented task -see if they can correctly adjust the parameters of the function call

It is exactly the same here - all the introductory courses (and some of the more advanced ones) are taught by code dump. Result is that the average student who doesn't program outside of school, comes away with a decidedly below-par understanding of programming.

Quote:

Original post by acadestuff Going back to the tutorial briefly, I just wanted to check that my understanding of VAOs was correct. I was under the impression that you only called glVertexAttribPointer once when you setup the VAO (or maybe again if the data changed) and not every time that you render your scene like the tutorial shows. In fact, I thought that was the main reason for them. I haven't implemented VAO yet and I just wanted to make sure I had it straight in my mind before I do.

Yes, that is the point behind the VAO extension. The 'tutorial' would be vastly more useful if it demonstrated correct code [smile]

Yes, yes, we all know DX10 > OpenGL 3.. I hope that the next iteration of OpenGL will pick up the ball again and rework their API, fix drivers, make the library "less C" and "more OO", go to bed with Nvidia and ATI for hardware support, etc.. :P I think there's a demand for a low-maintainance cross platform API, but MS doesn't seem to be interested in that (for natural reasons).

Quote:

Original post by trasseltass I hope that the next iteration of OpenGL will ... make the library "less C" and "more OO"

I may well be in the minority here, but I don't see 'less C' and 'more OO' as being desirable directions for Khronos to take. To be honest, vertex_array_objects cleared up a large number of my complaints about the API, and a similar treatment of graphics state would clear up the rest.

There is no real need to make the API C++ or fully object-oriented, since that reduces the ease of bridging into other languages, and any meaningful 3D program already uses some of the many wrapper-libraries which are available.