Most GL tutorials use deprecated legacy OpenGL 1.x, which is terrible from an efficiency standpoint and has very little to do with modern 3d hardware. In addition to using legacy API's, they are often plain badly written.
The same applies to many books on OpenGL. They use legacy GL and/or are written by clueless people who know very little about the hardware the code runs on. Then they get branded with a silly name like "Writing 3d apps for iPhone", because the books stand no chance in comparison with better GL books.
Don't ask me for book recommendations, I don't really know. The only one I've heard good things about is the very latest edition of the OpenGL Superbible.
And fixed-function OpenGL (which is still present in 4.0, of course) is, IMHO, a better learning environment for this stuff. Yes, "real" shader programmers implement their own matrix stack and projection matrices. Newbie ones can't.
I also started with the fixed function pipeline since we had to target OpenGL ES 1.1, and I have to admit, it's a great starting place for a newbie since you don't need to know everything up front.
I teach an introductory university 3-D graphics programming class, and I use legacy fixed-function OpenGL at the beginning, and then legacy GL + GLSL for lighting & textures.
But then my goal is not to teach people how to use some particular API. I want to introduce principles of lowish-level graphics programming. I need to use some API, of course, but I can choose that with a view toward how helpful it is in teaching concepts (and also system independence).
OTOH, if I were running some kind of training seminar for people who wanted to go out and write the world's greatest game as soon as they were done, then my approach would obviously be a pretty poor one.
If you learn it with the fixed function pipeline it is actually harder to understand the low-level concepts. Simply consider the color issue: calling glColor once will set the color for all vertices that you are going to emit; the hardware, however, does not work like that. Shaders on the other hand make it clear how the pipeline works.
Could you explain that?
I bookmarked this tutorial site. It looks pretty good, and I'm super rusty, since my expertise lies in gameplay more than graphics. It looks solid and non-stupid.
Bookmarking for reading later.
aptitude install p7zip
p7zip -d FILENAME
.7z 10782763 bytes basis
.tar.gz 17423885 bytes +61%
.tar.bz2 16493028 bytes +53%
Here's another one that's pretty good. Not as long but maybe a even a bit more thorough.
I've been making some screencasts recently, and I'll admit that they're not exactly "modern", as I'm using OpenGL 2.1. The main reason I'm still there is due to OSX-- I should probably invest in a modern Windows/Linux machine that at least runs OpenGL 3.3, so I can make something more up-to-date.
Anyway, bookmarked- thanks!
I'm using the example of Unreal Engine, first because it's extremely popular but also because their online "developpers' network" seems pretty well done: http://udn.epicgames.com/Three/TechnicalHome.html
OpenGL is a C api, so it's very natural to write introductory material for GL in C. Anyone is serious about wanting to use OpenGL should know enough C to read it and translate to whatever language you want. You also don't need to worry that much about language bindings or windowing system wrappers in the example apps. Example apps will also be more portable when written in C.
If this were written in Java, where there are no raw pointers or pointer arithmetic, etc, you'd have to use something like Java NIO Buffers or other abominations like that. You have to use raw pointers with OpenGL, since you do DMA transfers to upload and download geometry and texture data to and from the GPU. This is done with explicit transfer calls (with a pointer to the data) or with memory maps (where you get a pointer to a page aligned buffer that's ready for DMA transfer).
This is just another example on how every language that doesn't allow you to use pointers (for "security" reasons) will have something more complicated to replace them.
NOTE: if you really want Java versions, you can go ahead and write them. 10 years ago many people used the NeHe tutorials to learn OpenGL (don't touch them in 2011) and they were ported to pretty much any language and windowing framework out there. But they were ported bu individuals in the community, not by the original author.
Just because it's a C API doesn't mean it isn't used in other languages or has to be used in C. C can be unforgiving on the novice, so battling C while trying to learn OpenGL concepts can quickly become a losing battle. Portability is at the cost of complexity, setting up a C/C++ OpenGL cross platform build environment is not a piece of cake, especially on Windows.
C does allow low level access to memory, while this is powerful it also adds complexity. Things like loading a text file or image file aren't straightforward. Many libraries are in various states of disrepair. Getting a crash course in static vs dynamic libraries, linker settings, dependency/DLL hell detracts greatly from the learning experience.
Suggesting that allowing the programmer to use a buffer object or array in a call to GLBufferData would be somehow more complicated than wrangling with pointers & memory allocation is something I'll have to firmly disagree on.
Even if a novice reader is not familiar with C at a very deep level, it's not that different from other programming languages. You should be able to read C and grasp the basic concepts of storing objects in memory, because a lot of OpenGL is about storing stuff in memory and you have to think about pointer alignments and stuff like that.
And besides, if you're writing example applications for a book or a tutorial, you should probably stick to very simple C code anyways. The kind that anyone can read to some degree.
Please note that I did not advocate that the reader must write their own projects using C, even if the book examples are in C. They can pick any other language they feel comfortable in. Just be prepared to deal with binding libraries and windowing toolkits and all the little things that you need.
Programming the GPU is one of the most hostile programming environments out there. You might not have a debugger available and you can't even debug with prints, you have to deal with memory explictly, drivers are buggy and a small mistake in your program might crash your computer partially or fully or cause very unintended consequences. I would not recommend for a novice who can't deal with C code to go there. This is true whether you use C or not. Even with WebGL.
Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming. Then it's actually better to take a 3d engine that deals with 3d models, lights and cameras and stay away from OpenGL, which is basically a very complicated way of drawing triangles very fast.
A lot of stuff you said about C being difficult in practice, libs that are broken, difficulty on setting up on Windows, etc are true. However, they don't really apply to using it as a language in programming examples in a book or a tutorial.
What 3D engines would you recommend? I've looked at OpenInventor and Coin3d briefly but I'm interested in solid modelling as well, rather than 'just' visualisation. I'm guessing there's no such thing as an well documented and easy to use open source equivalent of the Parasolid or ACIS kernels? :-)
Maybe this will be controversial, but OpenGL probably isn't something a novice programmer should be tackling.
There's no time like the present to expand your knowledge. If you can't read C or assembly, you're missing out on quite a lot.
This low-level interaction with memory is pervasive in OpenGL's design. These features are so intrinsic to how OpenGL works that no wrapper can completely abstract them away.
I recently tried to learn it for Android games (so Java) working from a C++ book, and I eventually gave up. If I see a C-style array, what am I supposed to have there? A straight array? An Array? A buffer? Do we all mean the same thing by a float? My library looks a bit different -- I've got a similar function with a different prefix or suffix -- is it the one you're talking about? Even the same function expecting a different number of arguments is somewhat crippling when you don't know what they do, and don't have the vocabulary to understand what the documentation means.
OGL isn't easy to learn, and I don't think you can do the language translation easily until you've already learned it.