Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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.


* the hardware, however, does not work like 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: