[strayptr]

This domain is unique in that it's not a good idea to read. The most effective way to navigate this territory seems to be: Think of a simple goal, then force yourself to solve it. Don't look up how to solve it until you're so frustrated that you want to throw your monitor across your room.

Actionable advice: Set up a program such that you have an array of pixels. Say, 512x512. Now write a while loop which randomizes those pixels. Finally, figure out some way to "create a window and put those pixels on the screen."

You now have a game loop. This is roughly how every game works at a basic level.

The next step is to realize that a triangle is the fundamental way to draw shapes quickly. Want to draw a square? That's two triangles. Want to draw a humanoid? Sounds complicated, but artists approximate humanoids with a combination of spheres, cylinders, cubes, etc. And all of those can be divided up into triangles.

So a triangle is therefore the first place to start in understanding graphics in general. What's the goal? "Create a data structure to represent a triangle. Now try to draw a white triangle into your little pixel array."

It's going to be tough. But tough work is good. I remember how difficult it was for me to even get a basic white triangle up on the screen. But the rewards are worthwhile, because at this point a lot of other things will start to click. A "vertex buffer" will no longer be mysterious, for example, because you'll immediately see that your triangle structure (whatever you came up with) was really just "a vertex buffer with three vertices." And then you'll start to wonder why graphics programmers came up with such complicated words to describe such simple concepts...

At this point, you'll have the ability to go in one of two directions: "Notch" or "Carmack." It depends entirely on what you find interesting. If you like the idea of making games, concentrate on creating Pong. (You have everything you need, because you just got a triangle up on the screen, after all.) If you like more along the lines of what the article talks about, then concentrate on creating a software rasterizer. "Software rasterizer" is another one of those terms that turn out to sound scary, but is way easier than you'd expect. It's hard in the same way that learning to ride a bike is hard: it'll take awhile, but you'll never forget it. After that, nothing else you ever do (in graphics) will ever seem even slightly mysterious. I have some thoughts on how to learn the latter, if anyone's interested.

[pavlov]

... then you'll start to wonder why graphics programmers came up with such complicated words to describe such simple concepts...

In general, the reason is that these were not the first concepts that they came up with. Often they started out with even simpler concepts that didn't even need names -- but it eventually turned out that these were too simple to offer good performance, or did not map adequately onto evolving hardware.

The original way to draw a triangle in OpenGL didn't involve vertex buffers at all. Basically you just said "OpenGL, draw me some triangles":

  glBegin(GL_TRIANGLES);
  glVertex3f(0, 0, 1);
  glVertex3f(1, 1, 1);
  glVertex3f(0, 1, 1);
  glEnd();

That was all -- no need to create buffers or bind them. The same simplicity extended everywhere: instead of writing and binding shaders, you just declared what kind of lights and materials you wanted before rendering your triangle.

But when we got programmable GPU hardware that could execute whole programs separately from the CPU, these old simple ways became a tremendous performance bottleneck and an obstacle to implementing more advanced rendering algorithms. On the desktop, all the old OpenGL APIs still work, but they were removed entirely from the mobile edition.

[ska]

   This domain is unique in that it's not a good idea to read.

crazy talk.

Sure, learn by doing; but there are great resources to help you understand far, far faster than you ever will by experimenting alone. If nothing else, there is good code to read, and classic texts.

[strayptr]

Mmhm. As with everything, it's a balance. It's important to understand that reading is one of the most effective forms of procrastination that has ever been invented. It's also the prism through which your entire future passes, but everyone already knows that.

For example, Carmack was able to "invent" BSP because he was (as far as I've heard) an avid reader of medical journals. Specifically, journals and papers about the graphics techniques they used at the time. The field of medicine turns out to be very lucrative for an ambitious graphics programmer, because they're often at the frontiers of what's currently possible. So apparently BSP was used in accelerating medical renderings, and Carmack was able to see their potential for realtime graphics. The only reason he was able to do that was by reading pretty much every possible thing.

None of that will help you unless you force yourself to do and not read, though.

[ska]

You stated "This domain is unique in that it's not a good idea to read."

This is just not true in either of its claims. It's not even useful hyperbole, really, it's just wrong.

Graphics programming is exactly like other domains of technical development, you will learn best by a combination of reading good summaries/examples of what is known, doing work on your own (not cutting corners), and talking to people that know more about that you do.

[strayptr]

And yet, if you proceed as if it were correct, you'll be amazed at what you'll accomplish. The comment I was replying to was essentially asking, "What would've helped you back when you were in my position?" Ten out of ten times, I'd choose to tell myself, "Stop trying to read about how graphics engines work. Figure out how to get triangles up on the screen, without copying someone else."

The best I can say is that my career began from that method. And by asking a lot of questions on IRC.

[ska]

Glad it worked for you, but that doesn't make it good advice. And doesn't change the lack of uniqueness. It's usually a mistake to generalize from your own experience, when thinking about pedagogy. I'd wager that most people would do ok following that advice as if it were true ... But not as well as if they'd read as well.

[_nedR]

>I have some thoughts on how to learn the latter, if anyone's interested.

gimme, gimme.

[percept]

Blogworthy!