

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

======
ggchappell
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.

~~~
vinkelhake
> 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
> 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.

~~~
Impossible
>Some just like making pretty pictures. Some are thinking of themselves as
future game-engine writers.

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.

~~~
twelvechairs
> I think there are much better options now than there were 15 years ago.

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)

------
tdicola
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
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...](http://www.arcsynthesis.org/gltut/History%20of%20Graphics%20Hardware.html)

------
arithma
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.

~~~
mikevm
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
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.

~~~
joebaf
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.

------
sdfjkl
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
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
You're right, it was 4.1 - it's been a while :)

------
JonD23
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...](https://www.youtube.com/playlist?list=PLRwVmtr-
pp06qT6ckboaOhnm9FxmzHpbY)

------
thekylemontag
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.

------
Executor
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?

