
Learning Modern 3D Graphics Programming - julian37
http://www.arcsynthesis.org/gltut/index.html
======
exDM69
This one of the only tutorials on OpenGL that is worth reading. This is the
one we recommend at ##opengl in freenode.

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.

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

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

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

~~~
stephth
* the hardware, however, does not work like that.*

Could you explain that?

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

------
nicolasp
PDF versions (including one in Kindle format) are available in the archives at
<https://bitbucket.org/alfonse/gltut/downloads>

~~~
johnsonman
Where are they? All I can find are the compressed copies of the html + source
files.

~~~
gravitronic
Inside that .7z archive are 3 PDFs in the root directory as well.

~~~
jws
.7z files are unpacked in Debian with:

    
    
      aptitude install p7zip
      p7zip -d FILENAME
    

And for what it's worth, I was annoyed at installing a package, but it is a
pretty slick compressor:

    
    
      .7z       10782763 bytes  basis
      .tar.gz   17423885 bytes  +61%
      .tar.bz2  16493028 bytes  +53%

~~~
wtracy
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. :-)

------
exDM69
[http://duriansoftware.com/joe/An-intro-to-modern-
OpenGL.-Tab...](http://duriansoftware.com/joe/An-intro-to-modern-
OpenGL.-Table-of-Contents.html)

Here's another one that's pretty good. Not as long but maybe a even a bit more
thorough.

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

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

------
rdouble
What is considered the canonical graphics book these days? Back in my time it
was Foley and Van Dam.

~~~
andywood
For real-time rendering on modern GPUs, I recommend
<http://realtimerendering.com/book.html>

~~~
LBarret
yep, this one is very good.

------
jacobolus
Previous discussion <http://news.ycombinator.com/item?id=2528740>

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

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

------
davidwparker
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!

~~~
binarycrusader
OS X Lion has OpenGL 3.2 if your hardware supports it.

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

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

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

------
bbrizzi
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>

------
ejenkinsiii
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

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

------
felipemnoa
I wished it were in pdf. Is really annoying to have to follow the links in
HTML.

~~~
pbhjpbhj
Perhaps one of these will help <http://www.pdfonfly.com/>,
<http://www.htm2pdf.co.uk/> ?

------
pcestrada
Is there a paper book version? Didn't see it on amazon.

~~~
_delirium
It's a work-in-progress that I believe he's considering eventually publishing
as a book. New chapters are still being written, though; for example, Chapter
VI is currently just a 2-sentence stub.

------
gizmo
Has anybody found a PDF version?

------
miloco
A Java version of this would be great. A lot of it I can follow but there are
some parts which look totally foreign.

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

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

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

~~~
willyt
> 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? :-)

