6 ms·

I appreciate efforts like this. But in many ways (that aren't their fault!) they annoy me. I've been using and/or teaching GL pretty much since it came out. An

I appreciate efforts like this. But in many ways (that aren't their fault!) they annoy me. I've been using and/or teaching GL pretty much since it came out. And every new version makes it more difficult to learn. Once upon a time you did a few glVertex and glColor calls, set up transformations, and maybe some materials and lights, and there you were. If you wanted to be really cool, then you used a texture. Nowadays even a Hello World is supposed to manage various buffer objects that interact in complicated ways, and to include code in multiple programming languages, at least one of which is never used outside of graphics. So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon. I've had great fun with OpenGL through the years, and I still do, but I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve.

joebaf 12y ago
I agree that simple 'hello triangle' is not that simple any more. When I taught OpenGL I also used good old fixed functionality - just to show how the basics works. Then (in the next lesson) I usually tried to move to modern style. Another thing is that Rendering Techniques are moving so fast that it is hard to keep up with the pace.
AceJohnny2 12y ago
> I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve. Why would they? I don't mean to be antagonistic, instead I want us to look at the incentives of standards developers. What they're trying to do is make an old API perform new tricks and perform faster. In doing so, they will implicitly be answering the requests of people at the height of their field, as those are the people who need the standard to evolve for their needs. Beginners aren't even considered. That's a shame in the long run.
- ggchappell 12y ago
  You're right; that seems to be the way these people think. But still, I have an answer for them: > Why would they [give some thought to beginners]? Because they want there to be a next generation of OpenGL experts. Once upon a time there was OpenGL and there was DirectX, and an awful lot of people chose DirectX. Today every week brings a new API/framework/language. Most of these quickly die a well deserved death, but some don't. The competition for developer mindshare is fierce. Why not target beginners? The answer seems to be that they wanted the API to be cleaner and easier to implement. Starting with GL 3.0 they've been tossing out the old cruft to get a more focused, streamlined API. That sounds good, but I think it's idiotic. Everyone still implements glBegin anyway. The ARB's approach has made the maintenance of API implementations more complicated, not less.
vinkelhake 12y ago
> So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon. OpenGL is a fairly low-level API. If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?
- ggchappell 12y ago
  > If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them. > ... what is the point of leading them into a dead end? That's a good question -- one I've had to give substantial thought to. There are really three aspects to VBOs/EBOs. (1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes. (2) Data format. Arrays of attribute values. (3) Storage management. Buffer objects. If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers. OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others. Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3). So then I move to vertex/element arrays, focusing on issue (2). Lastly, buffer objects, and issue (3) is done. Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.
tdicola 12y ago
I agree that it's annoying how complex 'simple' examples are but am not sure the OpenGL standard is the right place to inject a beginner friendly interface. A lot of the complexity like managing buffers and graphics memory are a result of the more capable 3D hardware we have today. A better thing to do would be to have a nice beginning library built on top of OpenGL and which abstracts away a lot of the gory hardware details to expose a simpler immediate mode style or scene graph interface.
svdree 12y ago
Beginners can always use something like Unity3D, or any of the other gazillion libraries that are available. IMO beginner-friendly stuff has no place in the spec. It seems to me that many people these days aren't willing to invest time to learn certain technologies anymore. They just want to be able to slap a bunch of components together quickly, and don't want to invest time in actually learning anything. Well, good luck doing that with 3D. Even if you manage to find an API that is simple enough, you probably still don't understand the 3D math behind it, or why your renderer is dog slow even though you only draw a handful of triangles
binarycrusader 12y ago
I frequently hear WebGL recommended instead as a good place to start; that way you get 'modern' OpenGL without much of the hassle.
Impossible 12y ago
The thing is, OpenGL shouldn't be a learning API, especially considering on many platforms (Mac, Android, iOS, Linux) its the lowest level way to get access to all vendor's graphics hardware. The primary customers of the API should be developers of large frameworks, engines and applications and it should be the lowest level abstraction that maximizes performance and compatibility. As GPU hardware becomes less fixed function and more complex the API will naturally become less beginner friendly. Beginners today should be starting with a game engine or a creative coding framework. There is an abundance of high or mid level options (processing, three.js, Unity 3D, Unreal 4, openframeworks, ShaderToy, etc.) that allow people to play with and learn about different parts of the graphics pipeline while getting immediate and cool results. Processing, for example, lets people do the equivalent of glVertex\glColor immediate mode calls with far less boiler plate than GLUT, SDL or GLFW, and it's easy for them to add and learn about the transform state, fixed function lighting, shaders, etc.
- joebaf 12y ago
  I like your idea. When starting with Unity/UDK/etc they would get some basic understanding of how it 3D rendering works. Then, if they want, they could go deeper and learn low level api like DX, OGL
greggman 12y ago
I am glad they don't give thoughts to beginners. Low Level Graphics APIs are about perf and giving as much access as possible to the hardware in as much as possible a cross platform way. It's called layering. Let OpenGL focus on the lowest level. Use other libraries for higher levels. People learning should choose what the right level for them is. Whether it's starting with Unity3D or Unreal and not worrying about the low level details, or going slightly lower level with some other library. Adding more high-level beginner friendly features to OpenGL is the worst possible thing you could do. It clutters the API and needlessly brings all kinds of baggage with it. For those who do want to learn though I'd suggest starting with WebGL. It's way way easier. You don't have to deal with all the system specific setup. You don't have deal with figuring out how to get some image loading library to compile and link. If you want to get started instantly use [three.js](http://threejs.org http://threejs.org) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/ http://greggman.github.io/webgl-fundamentals/) BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.
- zeidrich 12y ago
  I'm glad, when I started to learn OpenGL I used web tutorials and most of them were written in immediate mode. It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all. There's a big difference between Unity which is "Here's a model, display it at this position and this scale" and writing your own .OBJ loader and arranging vertices and outputting the data to the screen, even if you're doing it inefficiently. Sure when you use immediate mode it's terrible performance wise and very restrictive, but once upon a time, immediate mode was the only thing. Many people who are skilled started with it, and made use of new features as they became available. Sure jumping in and doing it the right way is better, but it's also really hard. For a parallel example for C, we have printf to write to a console. In most applications you're not actually using printf to print to an 80x25 console, you're rendering your text to a window or some other output stream. But we leave print in the stdio library, because it's handy for testing things quickly, for learning, for getting quick and dirty output when performance is less important. Immediate mode is easy. Begin, add vertices, end. You can do a lot with it. You don't want to write a graphics engine in it, but that's no reason to discard it. You don't want to write a client app with console output but that doesn't mean it's irrelevant. I do agree you shouldn't hold the language back to support these way of doing things, but there's no point in now letting them exist. WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it, and then there's the reliance on js.
jgh 12y ago
Honestly the thing I found most helpful when learning how opengl works is to write a rasterizer from scratch. Then all of the buffers and shaders and everything made a lot more sense after that.

joebaf 12y ago

I agree that simple 'hello triangle' is not that simple any more. When I taught OpenGL I also used good old fixed functionality - just to show how the basics works. Then (in the next lesson) I usually tried to move to modern style. Another thing is that Rendering Techniques are moving so fast that it is hard to keep up with the pace.

AceJohnny2 12y ago

> I wish the people in charge of the standard would give some thought to beginners and the increasingly awful learning curve. Why would they? I don't mean to be antagonistic, instead I want us to look at the incentives of standards developers. What they're trying to do is make an old API perform new tricks and perform faster. In doing so, they will implicitly be answering the requests of people at the height of their field, as those are the people who need the standard to evolve for their needs. Beginners aren't even considered. That's a shame in the long run.

ggchappell 12y ago
You're right; that seems to be the way these people think. But still, I have an answer for them: > Why would they [give some thought to beginners]? Because they want there to be a next generation of OpenGL experts. Once upon a time there was OpenGL and there was DirectX, and an awful lot of people chose DirectX. Today every week brings a new API/framework/language. Most of these quickly die a well deserved death, but some don't. The competition for developer mindshare is fierce. Why not target beginners? The answer seems to be that they wanted the API to be cleaner and easier to implement. Starting with GL 3.0 they've been tossing out the old cruft to get a more focused, streamlined API. That sounds good, but I think it's idiotic. Everyone still implements glBegin anyway. The ARB's approach has made the maintenance of API implementations more complicated, not less.

vinkelhake 12y ago

> So I'm a rebel. I still teach immediate mode. I'm well aware that this is The Wrong Way (tm), but my goodness, you can't throw profiles and buffer objects at people before they've even successfully animated a polygon. OpenGL is a fairly low-level API. If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. On the other hand, if your students are learning OpenGL to write such libraries/engines on their own then what is the point of leading them into a dead end?

ggchappell 12y ago
> If your students just want to get something animating on screen without having to dive too deep then surely there are many libraries/engines built on top of OpenGL that will allow that. The reason my students are learning graphics programming vary with the student. Some just like making pretty pictures. Some are thinking of themselves as future game-engine writers. And of course, this being a university degree program, many of them just want to pick up some elective credit so that they can graduate. So I take a more short-term view. I teach low-ish level graphics programming so that my students will know low-ish level graphics programming. What they do with it after that is up to them. > ... what is the point of leading them into a dead end? That's a good question -- one I've had to give substantial thought to. There are really three aspects to VBOs/EBOs. (1) Capabilities of the graphics system and the data it needs. We are dealing with a system that can render (for example) triangles arranged in strips, specified via 3-D vertex positions and other attributes. (2) Data format. Arrays of attribute values. (3) Storage management. Buffer objects. If I do VBOs from day one, then I am introducing these three aspects all at once. It's tough to catch that they really are separate ideas; the concepts get all jumbled up, and understanding suffers. OTOH, if I start with immediate mode, then I can focus on the capabilities of the graphics system. What can it do, what information does it need from us, and how do we figure out that information. This is important stuff; it's good to learn issue (1) well without having to worry about the others. Students also get some quick success. They can write code to do interactive 3-D animation without having to worry about issues (2) and (3). So then I move to vertex/element arrays, focusing on issue (2). Lastly, buffer objects, and issue (3) is done. Yes, some people would call it a waste of time to talk about immediate mode. But even ignoring the above arguments, I can cover immediate mode in an hour, complete with a functioning demo written nearly from scratch. If that's wasted time, then it isn't very much wasted time.

tdicola 12y ago

I agree that it's annoying how complex 'simple' examples are but am not sure the OpenGL standard is the right place to inject a beginner friendly interface. A lot of the complexity like managing buffers and graphics memory are a result of the more capable 3D hardware we have today. A better thing to do would be to have a nice beginning library built on top of OpenGL and which abstracts away a lot of the gory hardware details to expose a simpler immediate mode style or scene graph interface.

svdree 12y ago

Beginners can always use something like Unity3D, or any of the other gazillion libraries that are available. IMO beginner-friendly stuff has no place in the spec. It seems to me that many people these days aren't willing to invest time to learn certain technologies anymore. They just want to be able to slap a bunch of components together quickly, and don't want to invest time in actually learning anything. Well, good luck doing that with 3D. Even if you manage to find an API that is simple enough, you probably still don't understand the 3D math behind it, or why your renderer is dog slow even though you only draw a handful of triangles

binarycrusader 12y ago

I frequently hear WebGL recommended instead as a good place to start; that way you get 'modern' OpenGL without much of the hassle.

Impossible 12y ago

The thing is, OpenGL shouldn't be a learning API, especially considering on many platforms (Mac, Android, iOS, Linux) its the lowest level way to get access to all vendor's graphics hardware. The primary customers of the API should be developers of large frameworks, engines and applications and it should be the lowest level abstraction that maximizes performance and compatibility. As GPU hardware becomes less fixed function and more complex the API will naturally become less beginner friendly. Beginners today should be starting with a game engine or a creative coding framework. There is an abundance of high or mid level options (processing, three.js, Unity 3D, Unreal 4, openframeworks, ShaderToy, etc.) that allow people to play with and learn about different parts of the graphics pipeline while getting immediate and cool results. Processing, for example, lets people do the equivalent of glVertex\glColor immediate mode calls with far less boiler plate than GLUT, SDL or GLFW, and it's easy for them to add and learn about the transform state, fixed function lighting, shaders, etc.

joebaf 12y ago
I like your idea. When starting with Unity/UDK/etc they would get some basic understanding of how it 3D rendering works. Then, if they want, they could go deeper and learn low level api like DX, OGL

greggman 12y ago

I am glad they don't give thoughts to beginners. Low Level Graphics APIs are about perf and giving as much access as possible to the hardware in as much as possible a cross platform way. It's called layering. Let OpenGL focus on the lowest level. Use other libraries for higher levels. People learning should choose what the right level for them is. Whether it's starting with Unity3D or Unreal and not worrying about the low level details, or going slightly lower level with some other library. Adding more high-level beginner friendly features to OpenGL is the worst possible thing you could do. It clutters the API and needlessly brings all kinds of baggage with it. For those who do want to learn though I'd suggest starting with WebGL. It's way way easier. You don't have to deal with all the system specific setup. You don't have deal with figuring out how to get some image loading library to compile and link. If you want to get started instantly use [three.js](http://threejs.org http://threejs.org) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/ http://greggman.github.io/webgl-fundamentals/) BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.

zeidrich 12y ago
I'm glad, when I started to learn OpenGL I used web tutorials and most of them were written in immediate mode. It was nice to be able to quickly get some stuff going and then realize "Oh wow, my program is slow." Then I learned how to use VBOs and shaders and eventually got a pretty good handle on how to work it all. There's a big difference between Unity which is "Here's a model, display it at this position and this scale" and writing your own .OBJ loader and arranging vertices and outputting the data to the screen, even if you're doing it inefficiently. Sure when you use immediate mode it's terrible performance wise and very restrictive, but once upon a time, immediate mode was the only thing. Many people who are skilled started with it, and made use of new features as they became available. Sure jumping in and doing it the right way is better, but it's also really hard. For a parallel example for C, we have printf to write to a console. In most applications you're not actually using printf to print to an 80x25 console, you're rendering your text to a window or some other output stream. But we leave print in the stdio library, because it's handy for testing things quickly, for learning, for getting quick and dirty output when performance is less important. Immediate mode is easy. Begin, add vertices, end. You can do a lot with it. You don't want to write a graphics engine in it, but that's no reason to discard it. You don't want to write a client app with console output but that doesn't mean it's irrelevant. I do agree you shouldn't hold the language back to support these way of doing things, but there's no point in now letting them exist. WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it, and then there's the reliance on js.

jgh 12y ago

Honestly the thing I found most helpful when learning how opengl works is to write a rasterizer from scratch. Then all of the buffers and shaders and everything made a lot more sense after that.