Learning Modern OpenGL

http://www.codeproject.com/Articles/771225/Learning-Modern-OpenGL

by joebaf • 12 years ago

79 44 12 years ago

arithma• 12 years 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• 12 years ago

http://open.gl is a fantastic resource.

mikevm2• 12 years 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.

Amadiro3• 12 years 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.

higherpurpose• 12 years 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.

tomn• 12 years 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.

Amadiro3• 12 years 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

ggchappell3• 12 years 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.

joebaf3• 12 years 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• 12 years 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.

ggchappell3• 12 years 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.

vinkelhake2• 12 years 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?

ggchappell3• 12 years 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.

kbenson2• 12 years ago

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?

Because it lets them get feedback along the way while exposing them to some of the concepts they will be using later?

Taken to the extreme, that statement is the same as saying 'If your students aren't ever going to print "Hello World!", why ever use that string? They should be finding something more relevant to their eventual goal.' That is, as stated, extreme, but you can extrapolate my point from that.

tdicola2• 12 years 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• 12 years 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• 12 years ago

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

Impossible2• 12 years 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.

joebaf3• 12 years 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

greggman3• 12 years 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) or if you want to understand how it works try [WebGL Fundamentals](http://greggman.github.io/webgl-fundamentals/)

BTW: Those fundamentals, could easily be adapted to C/C++ and current GL.

zeidrich• 12 years 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• 12 years 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.

tdicola2• 12 years 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/ 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• 12 years 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%20...

thekylemontag• 12 years 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.

sdfjkl2• 12 years 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/

[2] http://www.opengl-redbook.com/

Voltage• 12 years 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).

sdfjkl2• 12 years ago

You're right, it was 4.1 - it's been a while :)

JonD23• 12 years 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-pp06qT6ckboaO...

Executor• 12 years 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?

Learning Modern OpenGL

Related Stories