Learning Modern OpenGL
codeproject.com
codeproject.com
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.
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.
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.
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.
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?
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.
Both of these students will learn more using a framework or game engine than immediate mode OpenGL.
> I teach low-ish level graphics programming so that my students will know low-ish level graphics programming.
What you're teaching isn't the real graphics pipeline anymore or even an abstraction of it. It's limited high level graphics programming that both doesn't teach how modern high level graphics work is done and doesn't teach fundamentals either. You're really just teaching how to write code for 90s fixed function APIs. I agree that it is a valid stepping stone (many of us started there), but I think there are much better options now than there were 15 years ago. Anyway, OpenGL is not an educational library and making the lives of educators easier should not be a concern of Khronos (or anyone). As an educator you can always build your own framework that has the appropriate level of "low-ish" levelness but holds the students hands enough to not confuse them, if you don't feel that current options are sufficient.
What are these? (Honest question. I am aelf-taught, first in immediate mode so tend to agree with parent comment that this is a sensible approach. If there's a better way of understanding the pipeline than starting this way - I don't know it)
First, scrap immediate mode. Do as if it doesn't exist.
Second, since modern OpenGL is impossible to teach, write a higher-level layer over modern OpenGL. Tailor that layer to teach what you want to teach. My guess is, you can do even better than the immediate mode —for teaching purposes, I mean.
Third, teach your student how you have implemented the magic, bit by bit. Or teach them some new low-level stuff, and then ask them to implement one of your high level functions. And so on, until they get the whole thing. (Be careful with that approach, though: you probably don't want your students to just plug holes in a program.)
That way, you keep the tight reward loop, and you don't teach obsolete tech. As approachable as it is, you don't want to even suggest immediate mode can be used for serious development.
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.
I don't think I can extrapolate your point. It all boils down to what the student wants: quick results or to actually learn OpenGL?
All I'm saying is that if you want to learn OpenGL, there's little point in spending time on de facto deprecated functionality.
Students will never use the OpenGL immediate API in a production coding environment.
One of these is a much better didactic stepping-stone than the other.
In C, the canonical hello world example can help teach about the program starting point, return codes, argument passing, and IO. This extremely simple program can help the student learn these core concepts, even if in practive their program may ignore all of that for main except what the instruction starting point is.
Was the exercise pointless, or did it help cement core concepts which may help later?
No, not a single one.
immediate mode had gl_Vertex, gl_Normal, gl_Color. Those are all gone. immediate mode had lighting, that's now hiding the fact that modern GL has no lighting, you have to write it yourself. Old GL has no normal maps, no opacity maps, no specular maps. Old GL had a matrix library. That's gone to.
You learn almost nothing from immediate mode GL that is relevant to modern GL.
You could argue you learn about some common 3D concepts like a projection matrix and a model matrix but since you don't actually work with the math in old GL you aren't really learning anything more than you could learn from any other 3D library built on top of GL.
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
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.
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.
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.
Unfortunately this doesn't always work. For some programs (typically small ones, not really representative of common usage) the deprecated functionality will beat out the modern functionality in performance, until you scale up. I've seen this several times with display lists in particular.
Which will typically leave newbies with the feeling that the new functionality is crappy and slow.
That's the important point. That one upon a time was invented 23 years ago. It was the wrong model but it took ~15 years to figure out that.
The problem with "beginner mode" is who decides what goes in it? You want what you had 10-15 years ago. Why is that the right level? Maybe it should support 1000 lights instead of 4? But that would require using deferred rendering under the hood. Maybe it should support shadows, oh but which kind as their are 10-15 techniques for shadows each with their own tradeoffs. Maybe you want it to support normal maps, or opacity maps, or specular maps, or glow maps. Maybe it should use physics based lighting because that's far easier for artists.
That's the reason all of that cruft was pulled out. OpenGL is no longer a 3D library. It's a 3D rasterization library. You build a 3D library on top of it. You choose the features you think your beginners need.
If you want your old style immediate mode GL then go use regal (https://github.com/p3/regal). Hopefully people will come out with better ways to start. (like three.js) That old school way is not the best. It was just one of the first. They figured out it was the wrong thing at the OpenGL level and moved on.
I'm happy you're nostalgic about your beginning experiences. People starting out today should start agruably somewhere else though.
> WebGL is pretty cool but in my experience still has some compatibility issues with browsers rendering it
not nearly as many issues as OpenGL because unlike OpenGL, WebGL has conformance tests
http://www.khronos.org/registry/webgl/sdk/tests/webgl-confor...
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...
* 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.
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.
- 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
Also, not even a mention of the OpenGL Red Book[2]?
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).
https://www.youtube.com/playlist?list=PLRwVmtr-pp06qT6ckboaO...
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.