That looks like a fair bit of boilerplate, and a shitty tutorial with comments that mostly just repeat what the code says, but the API doesn't look unusable.
Honestly I think your examples are both genuinely less comprehendible to someone without a deep understanding of GL going in than my example.
It’s a very bad, non-object oriented API in an object oriented language. It was designed for and by people who know GL in other C like languages, not for people who know JavaScript. It is unlike any other part of the language.
The fact that I have to write a shader myself, as a fricken string like I’m writing SQL over here, just to draw a triangle is absurd. There should at the very least be some sort of provided builder for simple shaders.
Yeah, they probably are, I didn't intend them as tutorials but as a better representation of the actual scutwork necessary to draw a triangle.
Object-oriented languages are not a good way to do 3-D rendering. If you want to write pixel shaders in JS you can totally do that but you will have to run them on the CPU; as it happens I wrote a program last week that works that way: http://canonical.org/~kragen/sw/dev3/trama. If you want to run them on the GPU you need a language that exposes the GPU's capabilities.
In essence your primary complaint is that the GPU instruction set is not object-oriented (and neither is your database). Well, you can design your own GPU, but I've got some bad news for you about Verilog, Chisel, and BlueSpec! And you may find out that the real problem is that solid-state physics isn't object-oriented, so your OO GPU will end up underperforming, like the Burroughs B5000 and the Symbolics 3600 (hopefully not as badly as the Intel iAPX432). You'll probably have more success writing an object-oriented database.
However, I do agree that WebGL is a bad API, because boilerplate is never acceptable.
Examine it more closely; you will find that it is a dynamical system composed of sextillions of parts, constantly entering and leaving the rock, and that the boundaries between the rock, the table, and the air are very fuzzy indeed. It isn't even encapsulated, nor are its interactions with its environment mediated by messages to which it freely chooses a response; it is its environment.
Your insight is remarkably well-written. I wish we could see our bodies in the same way, all of the time. The world might be a kinder place overall. Do you meditate?
But even if we're arguing physics, that's debatable. The shape and toughness of the rock are actually an effect of forces between the atoms composing the rock, and the weight of the rock is actually the interaction between the mass of the rock and the earth. The color of the rock is the effect of the interaction between the molecules in the rock and photons (which are themselves wave-like) and then the interaction between that light and the cells in your eyes.
Objects are a convenient day-to-day model in real life and software, but there are more "functional" models that comprise the object model.
I don’t see how someone not understanding GL first can do anything useful with it. Like, what would such people even use it for? If they need a complete solution just use a plugin that displays some rotatable 3D model. But I really don’t see the value of planning for the lowest common denominator in case of a highly specialized domain specific API.
Holy living crap. I was all with it up until I saw the actual full HTML example. That is an incredulous amount of overhead for what is essentially one of the most basic and fundamental operations in *GL.
Comparing this to Canvas is almost like comparing assembly to C. I'm honestly very surprised.
Though boilerplate is never acceptable, most of that is constant-factor overhead, not per-triangle overhead, and tutorialspoint is not a site you should trust under any circumstances. See my links above for better sources.
If you put more vertices and indices in Step 2 you can draw an arbitrarily complex 3-D object with this same code.
And there's a lot of stuff in GLSL where you can program directly with high-level concepts like vectors, normals, and partial derivatives, instead of expressing them by hand the way you would in C.
Right, and that's what the glslCanvas project I linked above is, though in this case it's negative overhead if you're just counting the lines of code you have to maintain :)
Yeah, Canvas 2D is great, though it's not any more OO than WebGL, and I sometimes forget to create a new path and wonder why it keeps getting slower and slower with every frame. SVG is also pretty reasonable.
Neat, you do the math yourself and then render the tris/quads in canvas? I did something like that recently (in C/SDL, later RayLib). I found it amusing that to get performant 2D rendering you have to use a 3D API, so my "software rendered" 3D engine which just uses the gfx api for 2D draw calls ends up using 3D for the 2D under the hood...
There's at least one (great) game written like that though, Need for Madness with a custom 3D engine and just using java's 2D gfx api for rendering.
Except that WebGL didn't exist so I just had to use the 2-D <canvas>. There's probably some trick for getting antialiased polygon edges in <canvas> to not show cracks...
Once you get through the process of drawing a triangle on the screen then you're learnt 70% of the core of OpenGL. I think you're making the incorrect assumption of "wow if it takes this long to just get a triangle on the screen it must take 1000x as long to get an entire model of a watch" when really you're almost able to draw a model already, you just need to put multiple triangles on the screen now instead of just one.
