5 ms·

Can someone explain why the API design is such that it takes roughly ~100 lines of code and understanding of many different concepts (buffers, vertex/fragment s

by typon 9y ago

Can someone explain why the API design is such that it takes roughly ~100 lines of code and understanding of many different concepts (buffers, vertex/fragment shaders, uniforms, attributes, etc.) to draw a monochrome triangle on a canvas? I'm not trying to be snarky or say WebGL sucks (I have very little experience with it), I'm just wondering why the design choices have culminated into such an API?

dahart 9y ago
Flexibility and performance are the two driving forces behind the amount of template you need to get something on-screen. All the GPU API designs have gone the same direction. WebGL actually takes less template code than, say, Vulkan or Direct3d. Back when less template code was needed, we had fixed function pipelines that couldn't run shader code, and we were bound by all kinds of assumptions & limits. The APIs basically assumed you were doing perspective projection of textured triangles with Phong shading using point lights, for example. The APIs these days assume far less about what you want to do, and allow far more customization, at the expense of more setup function calls. That said, getting started really is a total nightmare, and there's lots of room for acknowledging that most people only have one of several basic pipelines. There's no reason we couldn't have some easy default setups in addition to all the flexibility. API designers would probably argue that templates are not in their purview, but it sure would be nice if GPU interfaces took a step or two in the ease of use direction.
- pjmlp 9y ago
  GL is the worst of graphics APIs regarding newbie support. While every other 3D API has support for math, textures, models, shaders, fonts, basic scene graph, GL leaves to the developers to hunt for 3rd party libraries. Khronos tried to change that by creating an SDK page, listing endorsed libraries, but it has not been updated in ages.
Jasper_ 9y ago
Because this is what a modern programmable pipeline looks like. You can go from that same ~100 lines of code to 80,000 triangles and have it still run well. You need: 1. A way to send opaque data to the GPU (this is a buffer) 2. A way to programmatically transform that data (this is a shader) 3. A way to specify input parameters to those transforms not found in the data (a uniform) 4. A way to decompose that opaque data into tangible (an attribute) With not much more code, you can go from that to something like e.g. http://magcius.github.io/pbrtview/ http://magcius.github.io/pbrtview/ using the same exact primitives. This is an example of a custom WebGL2 engine (not using three.js) in action. Leaf through https://github.com/magcius/pbrtview/blob/gh-pages/src/models.ts https://github.com/magcius/pbrtview/blob/gh-pages/src/models... and you'll still see the same createBuffer, bufferData, drawArrays. There's not much more that I added on top.
- esrauch 9y ago
  The truth is a tiny amount on top could significantly reduce the boilerplate for true beginners: a spec defined trivial fragment and vertex shader that has an associated glBindDefaultShaders() would already go a long way. The truth is that it doesn't really make sense to make the "render one triangle" easier since it only makes sense to use OpenGL if you are going to go deep on how it works, so accelerating the first two days down to one day isn't going to make a huge impact on the learning curve (compared with other apis where cutting the first two days to one would be a huge deal).
- meritt 9y ago
  You seem to have a good grasp on modern 3D programming -- Do you have any books recommendations that provide a solid overview of the topic?
  - Jasper_ 9y ago
    My two biggest shelf pulls are Real-Time Rendering [0] by Akeine-Moller, Haines and Hoffman. 3D Math Primer for Graphics and Games [1] by Dunn & Parberry [0] https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240 https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akeni... [1] https://www.amazon.com/Math-Primer-Graphics-Game-Development/dp/1568817231/ https://www.amazon.com/Math-Primer-Graphics-Game-Development... I also read a ton of presentations and papers. Highly recommend the famous PBR SIGGRAPH course notes [0], especially the intro to light & physics by Naty Hoffman. GPU-Driven Rendering Pipelines [1] is another recent goodie. [0] http://blog.selfshadow.com/publications/s2013-shading-course/ http://blog.selfshadow.com/publications/s2013-shading-course... [1] http://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf http://advances.realtimerendering.com/s2015/aaltonenhaar_sig...
verifex 9y ago
My own rather limited opinion is that accessing the Video Card via any technology involves using the facilities created by the video card itself, and that making it easier to use has been sidelined in favor of adding features for video game developers to allow much of the modern games to be created. There is probably a happy-medium between super simple API/engine for throwing polygons at the screen and having to build an entire 3D engine pipeline every time you want to use WebGL, but I'm not entirely sure we are there yet. In the mean time, some people use libraries to abstract away some of the uglier parts of WebGL so they can make things more quickly, my favorite is https://threejs.org/ https://threejs.org/
Risord 9y ago
One point of view is that because it's low level API. Flexibility has been valuated over easy of use. In general I think that offering low level API is ~only right way to do for real application platform. You can always make more easier opinionated high level API over it (like three.js). If platform has only high level API you cannot make it another way around. Good example about this issue is CSS. I have a bit strong opinion about this but I really think that fact that we cannot polyfill flexbox / grid layouts is "proof" that this technology is not good enough and lower level API would be better option (and current CSS model maybe built on top of that).
- pas 9y ago
  You might be familiar with the W3's CSS Technical Architecture Group's (TAG) Houdini task force, which started around 2015 (2014 http://lists.w3.org/Archives/Public/public-wtf/2014Dec/0003.html http://lists.w3.org/Archives/Public/public-wtf/2014Dec/0003.... ) to solve the problem you've mentioned. And it's looking quite good nowadays: http://snugug.github.io/magic-tricks-with-houdini/#/2/1/1 http://snugug.github.io/magic-tricks-with-houdini/#/2/1/1
fabian2k 9y ago
WebGL is essentially OpenGL ES, the same API that is used on mobile phones and a subset of OpenGL that is used on desktops. A lot of the verbosity is typically hidden in helper functions or libraries. I've used twgl.js (https://twgljs.org/ https://twgljs.org/), and it's much less code (and less potential for stupid mistakes in the boilerplate) than the pure WebGL API. There are still many concepts to understand, there is no way around it. You're mostly writing programs that are executed on the GPU itself, and you need to understand the limitations of that to write WebGL code. There are higher-level abstractions on top of WebGL you can use, if you don't want or need the low-level access WebGL gives you.

by typon 9y ago

dahart 9y ago

Flexibility and performance are the two driving forces behind the amount of template you need to get something on-screen. All the GPU API designs have gone the same direction. WebGL actually takes less template code than, say, Vulkan or Direct3d. Back when less template code was needed, we had fixed function pipelines that couldn't run shader code, and we were bound by all kinds of assumptions & limits. The APIs basically assumed you were doing perspective projection of textured triangles with Phong shading using point lights, for example. The APIs these days assume far less about what you want to do, and allow far more customization, at the expense of more setup function calls. That said, getting started really is a total nightmare, and there's lots of room for acknowledging that most people only have one of several basic pipelines. There's no reason we couldn't have some easy default setups in addition to all the flexibility. API designers would probably argue that templates are not in their purview, but it sure would be nice if GPU interfaces took a step or two in the ease of use direction.

pjmlp 9y ago
GL is the worst of graphics APIs regarding newbie support. While every other 3D API has support for math, textures, models, shaders, fonts, basic scene graph, GL leaves to the developers to hunt for 3rd party libraries. Khronos tried to change that by creating an SDK page, listing endorsed libraries, but it has not been updated in ages.

Jasper_ 9y ago

Because this is what a modern programmable pipeline looks like. You can go from that same ~100 lines of code to 80,000 triangles and have it still run well. You need: 1. A way to send opaque data to the GPU (this is a buffer) 2. A way to programmatically transform that data (this is a shader) 3. A way to specify input parameters to those transforms not found in the data (a uniform) 4. A way to decompose that opaque data into tangible (an attribute) With not much more code, you can go from that to something like e.g. http://magcius.github.io/pbrtview/ http://magcius.github.io/pbrtview/ using the same exact primitives. This is an example of a custom WebGL2 engine (not using three.js) in action. Leaf through https://github.com/magcius/pbrtview/blob/gh-pages/src/models.ts https://github.com/magcius/pbrtview/blob/gh-pages/src/models... and you'll still see the same createBuffer, bufferData, drawArrays. There's not much more that I added on top.

esrauch 9y ago
The truth is a tiny amount on top could significantly reduce the boilerplate for true beginners: a spec defined trivial fragment and vertex shader that has an associated glBindDefaultShaders() would already go a long way. The truth is that it doesn't really make sense to make the "render one triangle" easier since it only makes sense to use OpenGL if you are going to go deep on how it works, so accelerating the first two days down to one day isn't going to make a huge impact on the learning curve (compared with other apis where cutting the first two days to one would be a huge deal).
meritt 9y ago
You seem to have a good grasp on modern 3D programming -- Do you have any books recommendations that provide a solid overview of the topic?
- Jasper_ 9y ago
  My two biggest shelf pulls are Real-Time Rendering [0] by Akeine-Moller, Haines and Hoffman. 3D Math Primer for Graphics and Games [1] by Dunn & Parberry [0] https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240 https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akeni... [1] https://www.amazon.com/Math-Primer-Graphics-Game-Development/dp/1568817231/ https://www.amazon.com/Math-Primer-Graphics-Game-Development... I also read a ton of presentations and papers. Highly recommend the famous PBR SIGGRAPH course notes [0], especially the intro to light & physics by Naty Hoffman. GPU-Driven Rendering Pipelines [1] is another recent goodie. [0] http://blog.selfshadow.com/publications/s2013-shading-course/ http://blog.selfshadow.com/publications/s2013-shading-course... [1] http://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf http://advances.realtimerendering.com/s2015/aaltonenhaar_sig...

verifex 9y ago

My own rather limited opinion is that accessing the Video Card via any technology involves using the facilities created by the video card itself, and that making it easier to use has been sidelined in favor of adding features for video game developers to allow much of the modern games to be created. There is probably a happy-medium between super simple API/engine for throwing polygons at the screen and having to build an entire 3D engine pipeline every time you want to use WebGL, but I'm not entirely sure we are there yet. In the mean time, some people use libraries to abstract away some of the uglier parts of WebGL so they can make things more quickly, my favorite is https://threejs.org/ https://threejs.org/

Risord 9y ago

One point of view is that because it's low level API. Flexibility has been valuated over easy of use. In general I think that offering low level API is ~only right way to do for real application platform. You can always make more easier opinionated high level API over it (like three.js). If platform has only high level API you cannot make it another way around. Good example about this issue is CSS. I have a bit strong opinion about this but I really think that fact that we cannot polyfill flexbox / grid layouts is "proof" that this technology is not good enough and lower level API would be better option (and current CSS model maybe built on top of that).

pas 9y ago
You might be familiar with the W3's CSS Technical Architecture Group's (TAG) Houdini task force, which started around 2015 (2014 http://lists.w3.org/Archives/Public/public-wtf/2014Dec/0003.html http://lists.w3.org/Archives/Public/public-wtf/2014Dec/0003.... ) to solve the problem you've mentioned. And it's looking quite good nowadays: http://snugug.github.io/magic-tricks-with-houdini/#/2/1/1 http://snugug.github.io/magic-tricks-with-houdini/#/2/1/1

fabian2k 9y ago

WebGL is essentially OpenGL ES, the same API that is used on mobile phones and a subset of OpenGL that is used on desktops. A lot of the verbosity is typically hidden in helper functions or libraries. I've used twgl.js (https://twgljs.org/ https://twgljs.org/), and it's much less code (and less potential for stupid mistakes in the boilerplate) than the pure WebGL API. There are still many concepts to understand, there is no way around it. You're mostly writing programs that are executed on the GPU itself, and you need to understand the limitations of that to write WebGL code. There are higher-level abstractions on top of WebGL you can use, if you don't want or need the low-level access WebGL gives you.