
Long Live WebGL (2013) - joeyespo
https://nullprogram.com/blog/2013/06/10/
======
dahart
> This is because OpenGL is at its essence a 2D API.

I know @greggman has made this argument strongly and repeatedly. He’s not
wrong, and he’s definitely an authority on the subject, he’s done amazing,
amazing things for WebGL. But I keep bumping into this argument and I find the
strict insistence on the 2d part exceeding the argument’s usefulness.

It’s useful to know that you’re on your own to handle projections and
matrices. They aren’t built-in to the fixed function pipeline the way they
used to be. It’s useful to be able to think of WebGL as a rasterization
engine, and it’s useful to understand how the pieces fit together.

It’s not useful to claim that WebGL isn’t 3d at all ever, or to stick firmly
to that interpretation. WebGL does have support for 3d coordinates, 3d
textures, 3d matrices, and it’s main function is to present 3d graphics. Say
what you want about having to roll your own transforms, there is absolutely 3d
support and 3d intent designed into WebGL.

If you really want to insist that WebGL is a 2d API only, then get the Khronos
Group to say that. Currently the WebGL page says: “WebGL is a cross-platform,
royalty-free web standard for a low-level 3D graphics API based on OpenGL ES,
exposed to ECMAScript via the HTML5 Canvas element.” Appeal to them to change
the wording to 2d. As long as Khronos calls it 3d, then it’s 3d. Trying to
convince people otherwise on the internet can never work.

~~~
westoncb
After working with OpenGL for many years and then moving to higher-level
systems more recently (e.g. three.js), I found a useful way of viewing the
'essence' of the API: moving data around. It's not so much a '3D graphics API'
as it is a wrapper for interacting with a a GPU.

(A notable exception is shader code, which is largely doing custom geometric
or pixel transformations. But the rest of it is pretty much an API for moving
blocks of data in and out of the GPU.)

I think this is important to know, because the common perception is that
OpenGL, as an API for creating 3D graphics, would give you primitives for
talking about 3D objects/spaces—which for the most part it doesn't, aside from
essentially utility classes (e.g. vectors/matrices for working with 3D
spaces). In consideration of that, it's a pretty awful experience if you're
interested in describing 3D scenes, as opposed to developing new rendering
techniques or optimizing old ones or whatever.

So instead, it's an API well-suited to building actual 3D graphics APIs on
top—scene graphs, game engines, etc. My understanding is that Vulkan/Metal
take this to a further extreme, and I see it commonly mentioned in that
context—but it's true of OpenGL too!

It should be more common to warn beginners: learn OpenGL so that you can
understand the underpinnings of some other system you will eventually use to
describe 3D graphics—but this isn't the endpoint, don't build all your games
or whatever directly on OpenGL. You will have _so_ much more fun with a good
scene graph.

~~~
MaxBarraclough
> It's not so much a '3D graphics API' as it is a wrapper for interacting with
> a a GPU.

Mandatory link to Zed Shaw's blog post on the difference between an
'indirection layer' and an 'abstraction layer'.

 _Abstraction is used to reduce complexity. Indirection is used to reduce
coupling or dependence._

* [https://zedshaw.com/archive/indirection-is-not-abstraction/](https://zedshaw.com/archive/indirection-is-not-abstraction/)

~~~
westoncb
Hmm, but I didn't say it was an indirection layer nor an abstraction layer...

~~~
MaxBarraclough
If I'm understanding you and Zed correctly, you pretty much did, you just
didn't use Zed's terminology.

As you say, the intent of modern graphics APIs like Vulkan _isn 't_ to spare
the graphics programmer the hard work of writing low-level code. Instead the
intent is to provide a minimal indirection layer which does just enough work
to let graphics code work on any vendor's hardware, whilst preserving the
graphics programmer's ability to do low-level cleverness.

So game-engines and scenegraph systems are in the business of abstraction, but
graphics APIs are in the business of indirection.

~~~
westoncb
Okay, I see your point. _But_ indirection only enters the picture once you
introduce the possibility of _multiple_ graphics cards which are being
communicated with the same API—and I agree, that is an example of indirection.

However, it's not the role I was attempting to highlight. I was considering
the role of OpenGL/WebGL in relation to a single graphics card: if you
consider that situation, the API is still necessary and what it's doing is
neither (much) abstraction nor indirection. Instead, it's main task is
essentially conversion: the graphics card needs data in one format, javascript
programs assemble their data in another (I'm using data very loosely here; I
mean to include even the program source, since it's in a 'format' we can just
give directly to a GPU).

That said, even something like Vulkan does abstract a bit, and once you bring
in the possibility of multiple cards, the value of its role as an indirection
layer becomes clear.

------
AKluge
No, WebGL is not a 2D API. Neither is its predecessor, OpenGL. This comment
from the article is particularly misleading.

> OpenGL is at its essence a 2D API. The vertex shader accepts something as
> input and it produces 2D vertices in device coordinates (-1 to 1) as output.

This, and some of the comments in this thread, perhaps stem from a
misunderstanding of the projection matrices. The projection that you do
yourself is a projection from a large, arbitrary, 3D space to a small 3D space
where x, y, _and z_ are restricted to [-1, 1]. These are the device
coordinates
([http://www.vizitsolutions.com/portfolio/webgl/normalizedDevi...](http://www.vizitsolutions.com/portfolio/webgl/normalizedDeviceCoordinates.html)).
The hardware is very good at projecting this small 3D space onto the screen.

Indeed, it is possible to write a 3D program entirely within the device
coordinates. This example draws two triangles, without any projection, where
one is clearly behind the other.
[http://www.vizitsolutions.com/portfolio/webgl/translationMat...](http://www.vizitsolutions.com/portfolio/webgl/translationMatrix.html)
Drag the slider to see one triangle move behind the other.

Even this is a simplified explanation. There are a lot more details here,
including all the math:
[http://www.songho.ca/opengl/gl_projectionmatrix.html](http://www.songho.ca/opengl/gl_projectionmatrix.html)
This shows why the output from a vertex shader, gl_position, is a vec4. It is
definitely not a 2D value.

That said, yes, WebGL is great :)

~~~
ajross
I think the point was that the OpenGL framebuffer is ultimately a 2D space.
Whatever your input data and computation model, at the end of the data the
output from your computation goes into a set of arrays with two index
coordinates. That's a fairly specious point, maybe, but it's not wrong.

~~~
jmts
But surely since the memory that the frame buffer is encoded into is 1D,
OpenGL is really one-dimensional. /s

Sure, the frame buffer is 2D in the end - it has to be, in order to display on
a standard computer monitor - but surely the fact that OpenGL is able to
natively handle point data as 3D-homogeneous coordinates, and support for
techniques like depth buffering out of the box counts for more than any
argument that only really amounts to "after it is finished doing all its work
you just have a 2D image".

------
zerr
Is WebGL here to stay? As Apple deprecated OpenGL...

~~~
mcpherrinm
WebGL is already implemented on top of DirectX on Windows using ANGLE:
[https://en.wikipedia.org/wiki/ANGLE_(software)](https://en.wikipedia.org/wiki/ANGLE_\(software\))

As a result, operating system support isn't really relevant to browser
support, since ANGLE will eventually be able to target metal or vulkan on Mac
os

~~~
zerr
What about OpenGL? Is it worth learning now?

~~~
skolemtotem
Yes! I'd suggest learning OpenGL, then Metal, then Vulkan/DX12, which is how
I'd rank them from high to low level.

~~~
zerr
I'd prefer to stay at OpenGL level. Maybe some kind of standardized high-level
API pops up on top of Vulkan/Metal, for those who don't want to go that low-
level.

~~~
skolemtotem
Metal is actually not that bad to live in. Vulkan, on the other hand, is
micromanagement hell. I definitely agree with the people saying that it's for
"building your own OpenGL".

~~~
pjmlp
Worse, because they took the extensions concept and took them a step further.

Every couple of weeks there is a new version, and each card supports a certain
minor version.

[https://vulkan.gpuinfo.org](https://vulkan.gpuinfo.org)

------
pandaman
I have not used OpenGL much and don't know if you can actually output 2D
device coordinates, but I am sure it supports the same format the hardware
uses natively - 4D device coordinates.

With the 4D device coords it can do things, which make no sense in 2D:
clipping against view frustum (e.g. how do you clip against the front plane in
2D?) and perspective mapping.

