Hacker News Reader

Comment by ajross | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com