4 ms·

WebGL through Three JS

43 points by DanielRibeiro 14y ago

kevingadd 14y ago
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-graphics-pipeline-2011-part-3/ 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.
- tsvk 14y ago
  For me the slides (also previous slides that worked before) broke after the embedded Carmack Youtube video. Must be some conflict between WebGL and Flash.
Sarkie 14y ago
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. Here is my Gran Turismo clone. http://agentrunnerjs.apphb.com http://agentrunnerjs.apphb.com
- wwwtyro 14y ago
  They have a nice migration guide here: https://github.com/mrdoob/three.js/wiki/Migration https://github.com/mrdoob/three.js/wiki/Migration.
rossmckegney 14y ago
If you're having problems viewing the slides, visit http://get.webgl.org http://get.webgl.org It's not what we designed it for, but turns out that our material editor in http://studio.verold.com 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.
pyalot2 14y ago
Just wanted to mention that my demo (Deferred Irradiance Volumes) is not three.js. The credits for it would be http://codeflow.org/ 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.
brocoolifucker 14y ago
This page crashed my PC. Fedora Core 17 64 Bit, Firefox 17

43 points by DanielRibeiro 14y ago

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-graphics-pipeline-2011-part-3/ 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.

tsvk 14y ago
For me the slides (also previous slides that worked before) broke after the embedded Carmack Youtube video. Must be some conflict between WebGL and Flash.

Sarkie 14y ago

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. Here is my Gran Turismo clone. http://agentrunnerjs.apphb.com http://agentrunnerjs.apphb.com

wwwtyro 14y ago
They have a nice migration guide here: https://github.com/mrdoob/three.js/wiki/Migration https://github.com/mrdoob/three.js/wiki/Migration.

rossmckegney 14y ago

If you're having problems viewing the slides, visit http://get.webgl.org http://get.webgl.org It's not what we designed it for, but turns out that our material editor in http://studio.verold.com 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.

pyalot2 14y ago

Just wanted to mention that my demo (Deferred Irradiance Volumes) is not three.js. The credits for it would be http://codeflow.org/ 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.

brocoolifucker 14y ago

This page crashed my PC. Fedora Core 17 64 Bit, Firefox 17