Most of these slides don't seem to work. Can't tell if they require GL extensions I don't have, need to run in Chrome Canary, or what. (Firefox, GeForce GTX 670)
On a more pedantic note, the 'programmable graphics pipeline' slides are so inaccurate that it makes me slightly uncomfortable. It's okay to generalize some so that people get the idea of what's going on, but you're leaving out a lot of important details that help make it clearer why things work the way they do in modern 3d hardware.
For a starting point, look at how the modern pipeline is described here:
http://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-g...
Even with geometry shaders left out of the picture, you've got something like 6 'stages' in the pipeline, entirely ignoring all the incredibly complex magic that lives in the driver (and for WebGL apps, in the browser).
It might be better to instead show the flow of data through the CPU/GPU instead of showing pipeline stages - for example:
vertex buffers, index buffers, shaders, and draw calls that tie them together
primitives constructed from the indices and vertices
quads/spans/fragments/etc created from the primitives by the rasterizer
the z-buffer - what goes into it, where, who writes to it and reads from it
the pixel shader - what inputs it actually takes and what it produces
the actual output color data being written to the framebuffer
Really just pedantry at this point, but I don't think the existing pipeline diagram in the slides really says much useful.
If I had to pick one important lesson to convey when talking about modern pipelines, it would probably be how incredibly, massively parallel they are. hundreds or thousands of pixels/quads might be getting shaded at any given time, which is important to understand if you're trying to do interesting things with the GPU - it's not going to behave like your CPU and it may degrade in strange ways if you make the wrong demands.
It's not what we designed it for, but turns out that our material editor in http://studio.verold.com is a really nice way to see and learn about render settings. Even if you just run our intro tutorial to grab the Standford bunny, then turn the dials on its one material. See some of these principles in action, in Three.js.
I made a little PoC a while ago with three.js, what annoyed me was the documentation and the ever changing API and how examples were out of date straight away.
But it was still pretty nice making a "game" and pressing F5 to see my changes straight away.
Just wanted to mention that my demo (Deferred Irradiance Volumes) is not three.js. The credits for it would be http://codeflow.org/ (but don't worry, I've put that link on the demo long ago anyway).
Fortunately I've fixed a bug with the demo just today, so you're in luck. Unfortunately Windows ATI seems to have trouble with, I'm still trying to figure that one out.
On a more pedantic note, the 'programmable graphics pipeline' slides are so inaccurate that it makes me slightly uncomfortable. It's okay to generalize some so that people get the idea of what's going on, but you're leaving out a lot of important details that help make it clearer why things work the way they do in modern 3d hardware.
For a starting point, look at how the modern pipeline is described here: http://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-g... Even with geometry shaders left out of the picture, you've got something like 6 'stages' in the pipeline, entirely ignoring all the incredibly complex magic that lives in the driver (and for WebGL apps, in the browser).
It might be better to instead show the flow of data through the CPU/GPU instead of showing pipeline stages - for example:
vertex buffers, index buffers, shaders, and draw calls that tie them together
primitives constructed from the indices and vertices
quads/spans/fragments/etc created from the primitives by the rasterizer
the z-buffer - what goes into it, where, who writes to it and reads from it
the pixel shader - what inputs it actually takes and what it produces
the actual output color data being written to the framebuffer
Really just pedantry at this point, but I don't think the existing pipeline diagram in the slides really says much useful.
If I had to pick one important lesson to convey when talking about modern pipelines, it would probably be how incredibly, massively parallel they are. hundreds or thousands of pixels/quads might be getting shaded at any given time, which is important to understand if you're trying to do interesting things with the GPU - it's not going to behave like your CPU and it may degrade in strange ways if you make the wrong demands.