7 ms·

Learning Modern OpenGL

79 points by joebaf 12y ago

arithma 12y ago
OpenGL has been a huge wall for me. I always learn only to forget it. Remembering its quirks is almost impossible, and the recent articles about how inconsistently implemented it is (drivers, vendors, specs..) and how useless the extensions are claimed to be discourage even further.
- flexd 12y ago
  http://open.gl http://open.gl is a fantastic resource.
- mikevm 12y ago
  Given the amount of cruft OpenGL currently carries, the massive changes (read: rewrite) that will require for it to be a sane modern graphics API and the fact that several Khronos members that would probably not want any significant changes to the API (CAD companies, for example), wouldn't it make sense for the industry to dump OpenGL like yesterday's paper and converge behind a new, modern API? For example, AMD's Mantle.
  - Amadiro 12y ago
    No, that would make no sense whatsoever. You seem to be somewhat misinformed about GL... * OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already. * Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD. * AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it. Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.
    - mikevm 12y ago
      Thanks for schooling me :).
    - joebaf 12y ago
      Mantle is also not that important on Consoles - there you have thin driver layer, so Mantle would not help that much. Probably it will disappear in some years/months.
  - higherpurpose 12y ago
    In a way, it's already started from scratch - that's OpenGL ES. But I fear they want to "unify" the two soon such as that most of the cruft is added to OpenGL ES, too (just a presumption of mine). I think if they continue with ES on its natural path, it will simply become the default graphics APIs for billions of devices, without them doing much to push it one way or the other.
    - Amadiro 12y ago
      It looks more like Desktop GL might move to mobile devices soon. nvidia seems to be pushing really hard in that direction. But it'll remain to be seen where things go.
- tomn 12y ago
  I used to feel like this with OpenGL; the ammount of complexity to get my head around was so large that most of it had drained out of my ears between projects. I've been working on something recently using modern OpenGL though, and i've found it a lot more manageable. Because there's no longer a fixed pipeline -- you have to write your own shaders to be able to do anything 3D graphics related, the pltform is vastly simpler, to the point of being relatively easy to understand, if still a little complex to use. The API is still quite crusty; there's little in the way of abstraction, and you often have to make quite a few calls to do simple stuff, but it's conceptually a lot cleaner.
- Amadiro 12y ago
  Eh, a lot of the recent articles on hackernews about GL have been fairly low-quality and were badly researched (like the guy who complained about timer queries blocking, because he blatantly didn't understand how CPU/GPU communication works) No need to buy into the FUD. - if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall. - if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving. - extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D. - in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as: - things you do wrong - things you should do differently to increase performance - general debug information - information on memory usage and where your buffers are stored
ggchappell 12y ago
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.
tdicola 12y ago
Good overview article, but for a better deep dive into modern OpenGL and 3D graphics in general check out the (free) book at http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/ This is a fantastic resource that describes the theory and practical knowledge of using OpenGL today, like how to set up the programmable pipeline, write shaders, etc.
- scott_karana 12y ago
  The History section is well worth reading standalone, as well. Absolutely fascinating to get stories on the development of Hardware T&L, programmable shaders, the classic ATi/nVidia competition, et cetera. http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20Hardware.html http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20...
thekylemontag 12y ago
very well put together for those who are looking to actually learn OpenGL. Many people have a romanticized view of OpenGL, whereas in fact it is very very hard and confusing. For beginner teaching purposes, basically any other graphic library is preferable, and can still teach the same core design philosophies that OpenGL uses. For students / learners who know what OpenGL is, have maybe played around with the Hello World examples online, and want to really delve into the depths of OGL, this is a very good guide.
sdfjkl 12y ago
I've used Pyglet[1] to experiment and learn OpenGL using Python, although it needed some hacking to open up the 4.3 API on OS X (which only arrived at that version with Mavericks, having been stuck in a sad state for many years). Also, not even a mention of the OpenGL Red Book[2]? [1] http://www.pyglet.org/ http://www.pyglet.org/ [2] http://www.opengl-redbook.com/ http://www.opengl-redbook.com/
- Voltage 12y ago
  4.3 on OSX? Do you mean 4.1? I recently jumped to mac, and have been using OpenGL for a long time under Windows. The best I can get is an OpenGL 4.1 context on an up to date Macbook Pro (May 2014).
  - sdfjkl 12y ago
    You're right, it was 4.1 - it's been a while :)
JonD23 12y ago
Jamie King has great videos on OpenGL, among other things, on his YouTube channel. It looks like it was last updated 8 months ago with 99 videos spanning 14 hours. His commentary is awesome, so you will stay entertained. https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaOhnm9FxmzHpbY https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaO...
Executor 12y ago
I understand what/how to do VBO's but I don't know how to link it with game dev. If I have a HUD, entities, effects, terrain, do I have one VBO to handle all that data (and update it in my game loop)? Or should I split the VBO's into HUD/entities/effects/terrain/etc?

79 points by joebaf 12y ago

OpenGL has been a huge wall for me. I always learn only to forget it. Remembering its quirks is almost impossible, and the recent articles about how inconsistently implemented it is (drivers, vendors, specs..) and how useless the extensions are claimed to be discourage even further.

flexd 12y ago
http://open.gl http://open.gl is a fantastic resource.
mikevm 12y ago
Given the amount of cruft OpenGL currently carries, the massive changes (read: rewrite) that will require for it to be a sane modern graphics API and the fact that several Khronos members that would probably not want any significant changes to the API (CAD companies, for example), wouldn't it make sense for the industry to dump OpenGL like yesterday's paper and converge behind a new, modern API? For example, AMD's Mantle.
- Amadiro 12y ago
  No, that would make no sense whatsoever. You seem to be somewhat misinformed about GL... * OpenGL core profile is quite clean and lean. Both apple and intel have already decided not to implement OpenGL compatibility (where all the cruft sits). There are still a few things that can and should be cleaned up, but it's pretty great already. * Adding an additional API means there will be YET another thing vendors have to support and will be able to screw up, in addition to the already existing plethora of APIs: GL, D3D, DDX/GDI, OpenCL, VDPAU [or something like it], CUDA [or something like it], OpenMAX, Mantle. OpenVG, ... -- nobody is going to drop OpenGL or D3D for something like mantle, because that'd instantly lose you all your customers. Not even AMD. * AMDs mantle (which is, as far as we know, just a specific thing to their cards and not even portable to any other cards) is not an attempt to make things more stable, but an attempt by AMD to gain more control over the market (something they are in a good position to attempt right now, as they have control of the console market) and to push into the direction of a low-level interface that is strongly tied to their hardware model. Mantle as an API is (as far as we know) even lower-level than GL and D3D, and hence not very suited for most programmers and applications -- there are a lot more things you can do wrong with it. Don't believe all the FUD you read on hackernews. The main issue with OpenGL right now is that some vendors are doing a shitty job at it, which is mainly due to the heavy influence microsoft had on the gaming industry for a long time. GL is now making a major comeback due to linux, apple and mobile platforms gaining popularity, which will help rectify these issues over time.
  - mikevm 12y ago
    Thanks for schooling me :).
  - joebaf 12y ago
    Mantle is also not that important on Consoles - there you have thin driver layer, so Mantle would not help that much. Probably it will disappear in some years/months.
- higherpurpose 12y ago
  In a way, it's already started from scratch - that's OpenGL ES. But I fear they want to "unify" the two soon such as that most of the cruft is added to OpenGL ES, too (just a presumption of mine). I think if they continue with ES on its natural path, it will simply become the default graphics APIs for billions of devices, without them doing much to push it one way or the other.
  - Amadiro 12y ago
    It looks more like Desktop GL might move to mobile devices soon. nvidia seems to be pushing really hard in that direction. But it'll remain to be seen where things go.
tomn 12y ago
I used to feel like this with OpenGL; the ammount of complexity to get my head around was so large that most of it had drained out of my ears between projects. I've been working on something recently using modern OpenGL though, and i've found it a lot more manageable. Because there's no longer a fixed pipeline -- you have to write your own shaders to be able to do anything 3D graphics related, the pltform is vastly simpler, to the point of being relatively easy to understand, if still a little complex to use. The API is still quite crusty; there's little in the way of abstraction, and you often have to make quite a few calls to do simple stuff, but it's conceptually a lot cleaner.
Amadiro 12y ago
Eh, a lot of the recent articles on hackernews about GL have been fairly low-quality and were badly researched (like the guy who complained about timer queries blocking, because he blatantly didn't understand how CPU/GPU communication works) No need to buy into the FUD. - if you use core profile, modern GL, there aren't a lot of quirks. It's a fairly nice API overall. - if you target reasonably modern drivers, you won't typically find many inconsistencies and issues. If you do something unusual (like the latest idtech with megatexture) you might run into driver issues -- but that's just how things are, it's not the fault of the API. New functionality needs testing, and GPUs are still constantly evolving. - extensions are not useless. There are a huge amount of absolutely fantastic extensions. This is, IMO, the main strength of GL over D3D (and other APIs), which does not have a mechanism like this. If you know the hardware supports a certain functionality, there will most certainly be a GL extension to exploit that functionality, even if you can't with D3D. - in particular, KHR_debug is the best thing since sliced bread. It allows you to have the GPU driver diagnose your program for you, and give you hints such as: - things you do wrong - things you should do differently to increase performance - general debug information - information on memory usage and where your buffers are stored

ggchappell 12y ago

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.

tdicola 12y ago

Good overview article, but for a better deep dive into modern OpenGL and 3D graphics in general check out the (free) book at http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/ This is a fantastic resource that describes the theory and practical knowledge of using OpenGL today, like how to set up the programmable pipeline, write shaders, etc.

scott_karana 12y ago
The History section is well worth reading standalone, as well. Absolutely fascinating to get stories on the development of Hardware T&L, programmable shaders, the classic ATi/nVidia competition, et cetera. http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20Hardware.html http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20...

thekylemontag 12y ago

very well put together for those who are looking to actually learn OpenGL. Many people have a romanticized view of OpenGL, whereas in fact it is very very hard and confusing. For beginner teaching purposes, basically any other graphic library is preferable, and can still teach the same core design philosophies that OpenGL uses. For students / learners who know what OpenGL is, have maybe played around with the Hello World examples online, and want to really delve into the depths of OGL, this is a very good guide.

sdfjkl 12y ago

I've used Pyglet[1] to experiment and learn OpenGL using Python, although it needed some hacking to open up the 4.3 API on OS X (which only arrived at that version with Mavericks, having been stuck in a sad state for many years). Also, not even a mention of the OpenGL Red Book[2]? [1] http://www.pyglet.org/ http://www.pyglet.org/ [2] http://www.opengl-redbook.com/ http://www.opengl-redbook.com/

Voltage 12y ago
4.3 on OSX? Do you mean 4.1? I recently jumped to mac, and have been using OpenGL for a long time under Windows. The best I can get is an OpenGL 4.1 context on an up to date Macbook Pro (May 2014).
- sdfjkl 12y ago
  You're right, it was 4.1 - it's been a while :)

JonD23 12y ago

Jamie King has great videos on OpenGL, among other things, on his YouTube channel. It looks like it was last updated 8 months ago with 99 videos spanning 14 hours. His commentary is awesome, so you will stay entertained. https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaOhnm9FxmzHpbY https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaO...

Executor 12y ago

I understand what/how to do VBO's but I don't know how to link it with game dev. If I have a HUD, entities, effects, terrain, do I have one VBO to handle all that data (and update it in my game loop)? Or should I split the VBO's into HUD/entities/effects/terrain/etc?