Teaching OpenGL

[thokra]

Keep your changes local and you won't have a problem

[..] or some strategy to unbind everything right after usage.

I already said so and personally I haven't done otherwise for a long time.

I don't see how DSA helps with that.

I never said it did. But you're right, I should have made a more clear separation between setting state(i.e. bind-to-modify) and determining which state has already been set, e.g. the current number of draw buffers.

And what is a "readbuffer".

For me, that's a FBO bound to the GL_READ_FRAMEBUFFER target. Yeah, I know that's ambiguous and usually refers to one ore more attachments. But personally I like to think of an FBO that permits read operations as a read-buffer and one that permits draw operations as a draw-buffer.

My point is that OpenGL hasn't become more transparent just because some state has been thrown out. The remaining state is still as opaque as it has been when matrix and attribute stacks and so forth were still present.

[Alfonse Reinheart]

The problem being talked about was specifically dealing with old state which someone set for a previous object that doesn't apply to the next object to be rendered. The point being that the vast majority of state that needs to render something is bound into objects now. It doesn't matter if it's opaque or transparent; you just bind and render. You have an object, which is to be rendered with a particular VAO, using a particular shader, with a particular set of textures and uniform buffers, and rendered to a particular framebuffer.

As long as you have set these up correctly, the global state available that can trip up your rendering is much smaller than before. The most you have to look out for is your blending state. That's a substantial improvement in the locality of data that can break your rendering. That is, if rendering isn't working for some object, then you know it's a problem with that VAO, that shader, those textures, those uniform buffers, or that framebuffer. Or some of the still-global state.

The list of places that can be broken is fairly small.

[Ragnemalm]

I disagree, for instance with bind to modify remaining in imporant areas and especially when prototyping something quickly, such carelessness is still easy to miss. And it's not a matter of visibility, it's a matter of non-existence - something that existed earlier just isn't there anymore. That doesn't mean that in areas that remain, state is anymore visible than in areas that were removed. In larger systems, you still don't have any clue which buffer object is bound to GL_ELEMENT_ARRAY_BUFFER or if the current active texture unit has TEXTURE_2D and TEXTURE_CUBE_MAP set simultaneously, unless you don't have some strategy for tracking the state yourself, some strategy to bind to targets without collisions or some strategy to unbind everything right after usage. How many drawbuffers are active on the current FBO again? Is it a readbuffer? Oh, damn, that blend function isn't correct in this place. You can always use glGet*() to retrieve current state but nobody wants that in a real-time application. So, there's still plenty of state left that can lead to false results all over the place.

Are we still talking about teaching? In a teaching situation, when the students are just getting started with OpenGL, I think there is a certain improvement. They don't need to keep track of much more than the current textures, shaders and arrays.

FBOs is, IMHO, a later step. Yes, FBOs are messy. When I teach FBOs, we don't bother with all possible configurations, they get a working one from me and can work from there and for most, that configuration is all they need.

[Ragnemalm]

If I start with separate shader objects they won't be aware that a concept of monolithic program exists. Personally, I'm still don't use separate shader objects, but if it is something widely used (or will be), maybe it is better to introduce the concept as soon as possible.

I'd like to continue here a bit. The shaders-first approach is one that I had in mind, but in the end I went for the main program, minimal pass-though shaders and working with geometry first. But I am not sure I did the right thing. The simplest thing you can start with is to start writing vertex shaders, and then fragment shaders, before you even look at the main program.

We tried the shaders-first approach in some small projects separate from my main course and that worked pretty well, so maybe I should have taken that route anyway. Any other experiences, opinions? I can consider lectures about transformations, plus shading and basic lighting, and then a lab on shaders only. Then I can move to geometry, object representation, and have the next lab on the full program level. Texturing could be done without looking at the main program, but the more input data you have from the main program, the more you want to look at that data.

[Aleksandar]

I would rather start with GL context setup and accessing extensions; then shaders setup; then buffer-objects, vertex-attributes and uniform setup while having default vertex and fragment shaders. I'll try to make a course that guides students through the pipeline, step-by-step. At the beginning they don't have to know anything about shaders coding. They'll have default VS and FS. After attributes/uniforms setup, they'll start to code VS. FS still stays a black box, until the last stage. Of course, after mastering VS, they'll know what is what in FS, but they'll have to pass through TS, GS and TF before reaching FS. After FS a FBO will be introduced. It seems quite reasonable to follow the flow of data and introduce operations as they emerge in the pipeline.

[RickA]

I would rather start with GL context setup and accessing extensions; then shaders setup; then buffer-objects, vertex-attributes and uniform setup while having default vertex and fragment shaders. I'll try to make a course that guides students through the pipeline, step-by-step. At the beginning they don't have to know anything about shaders coding. They'll have default VS and FS. After attributes/uniforms setup, they'll start to code VS. FS still stays a black box, until the last stage. Of course, after mastering VS, they'll know what is what in FS, but they'll have to pass through TS, GS and TF before reaching FS. After FS a FBO will be introduced. It seems quite reasonable to follow the flow of data and introduce operations as they emerge in the pipeline.

That's interesting, I'm thinking for the course for my co-workers to do pretty much the exact opposite direction; FS -> VS -> uniform setups -> VBO + vertex attributes -> FBO

I'll see how it goes.

[Aleksandar]

Please share your experience with us.

I still think the education course should follow the pipeline stream.
GL setup -> buffers -> drawing functions -> VS -> (TF) -> TS -> GS -> (TF) -> FS -> FBO
Transform feedback (TF) may be explained just after VS, or after GS. TS is enough complex per se, so I wouldn't make things harder at that point.

[menzel]

Following in pipeline stream is in fact a very logical way to understand everything. But keep in mind that this way it takes very long to see 'colorful' results. From a motivation point of view getting the audience (=students) to create nice graphics on there own as quick as possible is key to keep them motivated. If you start on the other end with just FS you can say "ignore where the fullscreen quad and the textures come from, today we make nice effects and pretty images on a per fragment level" ;-)
When teaching graphics with OpenGL and not OpenGL with the needed background, I would start with transformations and ignore the GL specific setup steps for the first time, quickly move down the rest of the pipeline before I go back to look at the GL specific details of buffers, attribute locations etc (kind of a middle approach of the two extremes above).

[Aleksandar]

From a motivation point of view getting the audience (=students) to create nice graphics on there own as quick as possible is key to keep them motivated.

You are right! I need to do something other to keep them motivated.
FS should exist all the time. It would be very simple, but still has to support coloring and texturing. Lighting and texturing would be per vertex as long as FS becomes an active topic.

When teaching graphics with OpenGL and not OpenGL with the needed background, I would start with transformations and ignore the GL specific setup steps for the first time, quickly move down the rest of the pipeline before I go back to look at the GL specific details of buffers, attribute locations etc (kind of a middle approach of the two extremes above).

This would be a course on master studies. They already have enough knowledge about CG, transformations, lighting, texturing and legacy OpenGL.

[Aleksandar]

Yesterday I read "Teaching a Shader-Based Introduction to Computer Graphics" by Ed Angel and Dave Shreider, published at IEEE Computer Graphics and Applications Vol.32 No.2 (March/April 2011), and I'm really disappointed.
There is just a brief introduction to GL2.0/GLSL1.1 (although they mentioned GL 3.1/4.1) and claim that it is feasible to make proper introductory course using shader based approach and OpenGL.
I had expected more scientific approach to evaluate program they presented. But, there is no evaluation or even a statistic how students react to a new approach.