Learning Modern 3D Graphics Programming(arcsynthesis.org)
arcsynthesis.org
Learning Modern 3D Graphics Programming
http://www.arcsynthesis.org/gltut/index.html
17 comments
I think that's a little hard on legacy OpenGL. The things that people struggle with when learning 3D graphics are not the API. It's the math: homogenous coordinates, perspective projection, the idea of a matrix stack, texture mapping, filtering. Only once you've mastered this stuff can you even begin to worry about how to write shaders to implement them.
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.
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.
Fixed function OpenGL and immediate mode are definitely more newbie friendly than the programmable pipeline, but for learning I'd recommend avoiding low level APIs entirely at first and use a framework or engine that lets you work with higher level concepts. Fixed function OpenGL feels like a weird deprecated middle ground, if you are a beginner and want glVertex and a matrix stack you'll learn a lot quicker using Processing or Openframeworks than you will with straight fixed function OpenGL.
Can't agree more. I joined a game company a few years ago with zero graphics experience outside of writing a ray tracer in college and it was grokking the math and gaining an intuitive understanding of the transformation stack that was the hard part. Once you do though, man, you can't help but marvel at the beauty of it.
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 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 agree with you, but I think it does depend on the goal of the tutorial/class/whatever.
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.
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.
But isn't teaching 'lowish-level graphics programming' the point of this book?
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.
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.
* the hardware, however, does not work like that.*
Could you explain that?
Could you explain that?
On older fixed function hardware the fixed function pipeline mapped to hardware pretty directly. On modern GPUs most of the fixed function pipeline is emulated in drivers and shaders. So if you're doing "proper" low level graphics programming for modern GPUs you are writing shader code. Working with fixed function is writing for a low level abstraction that doesn't represent the way hardware actually works. It's true that using a 3D API at all is an abstraction that hides and simplifies many of the workings of the actual hardware, but modern APIs are much closer to actual hardware than legacy ones.
As a long time game programmer, I can tell you that the OpenGL Superbible is the only reference book anyone uses.
I'm not sure I'd recommend it as an introductory book though, especially for someone new to 3d graphics in general. In addition to being super-long, it's sort of weird as a tutorial (kind of strange selection of examples, pervasive dependency on the authors' custom utility library that isn't well explained, glossing over most of the relevant math). The one linked here looks much better from that perspective, though it's nowhere near as comprehensive as a reference.
I wasn't recommending it as an introductory book, just confirming the OP's assertion that it's the only book worth buying. It is a rare book about games/graphics programming that isn't completely worthless.
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.
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.
The OpenGL Superbible is a nice read; but - as already noted - not really suitable as an introductory tutorial by itself. You should at least couple it with a basic knowledge of linear algebra. 'Back in uni' (I don't like saying it, makes me look old) we used the Superbible in the "Computer graphics" course which was taught after "Introduction to Linear Algebra" and besides "Applied linear algebra for graphics".
Yeah, I clicked through to check it was talking about shaders and not the fixed function pipeline.
Bookmarking for reading later.
Bookmarking for reading later.
PDF versions (including one in Kindle format) are available in the archives at https://bitbucket.org/alfonse/gltut/downloads
Where are they? All I can find are the compressed copies of the html + source files.
Inside that .7z archive are 3 PDFs in the root directory as well.
.7z files are unpacked in Debian with:
aptitude install p7zip
p7zip -d FILENAME
.7z 10782763 bytes basis
.tar.gz 17423885 bytes +61%
.tar.bz2 16493028 bytes +53%Getting even further off-topic, the p7z utility can create archives compatible withe the normal .zip format (WinZip and friends can still uncompress them) that are a fraction of the size of what most zip utilities will produce. :-)
Neat! I'm confused though why the kindle format is just a reformatted pdf?
http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Tab...
Here's another one that's pretty good. Not as long but maybe a even a bit more thorough.
Here's another one that's pretty good. Not as long but maybe a even a bit more thorough.
That one is really great imo, because it doesn't use any utility libraries whatsoever which makes it much easier to understand if you're new to this stuff and have no clue what's what.
I agree with you, too many OpenGL tutorials add helpful utilities that really add no value for learning. More often they make things harder to port and more difficult to understand.
What is considered the canonical graphics book these days?
Back in my time it was Foley and Van Dam.
For real-time rendering on modern GPUs, I recommend http://realtimerendering.com/book.html
yep, this one is very good.
Previous discussion http://news.ycombinator.com/item?id=2528740
I've started reading this after I found it on an old HN post. I went through everything except chapter 12, 13, and the latest one that just came out. I would highly recommend learning OpenGL from this tutorial if you have no prior experience with opengl or computer graphics. This tutorial dives right into shaders in the very first chapter, where as the other sources (the red book, opengl superbible) still tries to teach your fixed pipeline rendering for several chapters before introducing glsl.
Nice. I wonder if there will be a kindle version available. Does anyone know how to automatically convert that website into a kindle ready format?
Thanks for great resource!
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'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!
OS X Lion has OpenGL 3.2 if your hardware supports it.
Could anyone recommend something similar for 2D programming in opengl, or anything else, or would that be covered in this tutorial? I'm mostly interested in building custom data visualizations beyond what is offered in the kind of visualization libraries I use like ggplot2.
You can do 2D just fine with what's in this tutorial - just set up an orthogonal projection and ignore the z-axis. It won't give you what ggplot2 does, but if you just need a way to draw 2D shapes, it will work.
Thanks, this is what I was looking for. I understand completely that ggplot2 is a much higher level abstraction of graphics. I want to build my own abstractions from first principles, but though I have a lot of programming experience, I have essentially zero experience with programming graphics from the ground up. It sounds like this will be a good place to start.
Is learning OpenGL from wthe ground up really the best way to go? The trend nowadays in programming seems to be to dive directly into the deep end. Wouldn't it be faster to just download a game engine like Unreal Engine 3 and go through its tutorial, learning about OpenGL along the way?
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
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
I've been been eyeballing this tutorial as an introduction to OpenGL/3d graphics, my question to HN is what's your opinion on learning 3d graphics with OpenGL vs. something like libcinder.org or www.openframeworks.cc which has bindings to OpenGL I'm not doing any game design mainly learning and understanding what the facilities of the API are and the logic of graphics programming
Looks like a great first book on OpenGL, written in a tutorial style. One can read this book first and then approach more complex (complete) books like OpenGL SuperBible.
I wished it were in pdf. Is really annoying to have to follow the links in HTML.
Perhaps one of these will help http://www.pdfonfly.com/, http://www.htm2pdf.co.uk/ ?
Has anybody found a PDF version?
[deleted]
A Java version of this would be great. A lot of it I can follow but there are some parts which look totally foreign.
I disagree with you.
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.
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.
I'll disagree with you as well.
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.
I'd honestly suggest someone starting out with OpenGL to try out WebGL. Loading shaders & textures is a snap(comparatively) & your build environment is your web browser & with that you get instant feedback. Javascript debuggers have also come a long way. Then later you can transfer your knowledge to other more performance oriented languages, if you need that.
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.
I'd honestly suggest someone starting out with OpenGL to try out WebGL. Loading shaders & textures is a snap(comparatively) & your build environment is your web browser & with that you get instant feedback. Javascript debuggers have also come a long way. Then later you can transfer your knowledge to other more performance oriented languages, if you need that.
Thanks for disagreeing with style!
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.
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.
> Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming.
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? :-)
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? :-)
>> C can be unforgiving on the novice, so battling C while trying to learn OpenGL concepts can quickly become a losing battle.
Maybe this will be controversial, but OpenGL probably isn't something a novice programmer should be tackling.
Maybe this will be controversial, but OpenGL probably isn't something a novice programmer should be tackling.
Maybe I should have said "C novice". There are many savvy programmers who have only glanced at C/C++ code or have never touched the thing. C can be a bit of a culture shock when coming from a dynamic or managed language.
I don't think it's unreasonable to say that basic familiarity with C is a prerequisite to low-level graphics programming.
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.
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.
>>C does allow low level access to memory, while this is powerful it also adds complexity.
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.
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 concur. While in most cases, some knowledge of Java or C will let you squint and read the other, when learning openGL for the first time, translating from another language makes it a lot harder.
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.
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.
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.