3 ms·

> The thing is, all APIs essentially move data around Technically true, but misleading to bring up. OpenGL is different because the primitives in it are explic

> The thing is, all APIs essentially move data around Technically true, but misleading to bring up. OpenGL is different because the primitives in it are explicitly about collections of data of specific types. Whereas an API that was 'about' 3D graphics would offer primitives related to the shape, position, and other aspects of the appearance of 3D forms and how they change in time. > It’s more helpful to know that WebGL is the API you need, if your goal is 3d graphics in a browser. I disagree. I think for almost everyone's needs, the API they need is something more like three.js. If you are writing a new scene graph or whatever, then WebGL is what you're looking for. More importantly though, it's about managing expectations of new users: yes, you can use OpenGL/WebGL to create moving 3D pictures—but it's going to be a linguistically awkward, and yet (potentially) performant, way of doing it. > These 3d graphics APIs intentionally don’t provide scenes graphs, for very good reasons. That would compromise their generality and speed. To be clear, I am not saying that OpenGL, Vulkan, etc. should provide scene graphs. I'm saying they are essentially hardware access layers with some special utilities for doing graphics stuff. They need to exist, and they should not be doing irrelevant things like providing scene graphs.

dahart 8y ago
> OpenGL is different because the primitives in it are explicitly about collections of data of specific types. Different than what? Three.js? OpenCV? Firebase? Instagram? All of these can be described as being explicitly about collections of data of specific types. This isn’t differentiating, you’re still describing all APIs. > Whereas an API that was ‘about’ 3D graphics would offer primitives related to the shape, position, and other aspects of the appearance of 3D forms and how they change in time. That is what WebGL provides. You’re trying to split a hair that doesn’t exist. I realize you’re trying to talk about the difference between immediate mode and retained state graphics APIs. Both are “about” 3D, and retained mode is not more 3D or more “about” 3D than immediate mode. I’d argue the other way around. Three.js is built on top of WebGL, it doesn’t do 3d graphics without WebGL, and the only thing it adds is retained mode state, i.e., a specific type of data. Three.js doesn’t do it’s own drawing, and it doesn’t add any 3D to WebGL that wasn’t already there, it only adds management of some host side memory so it can call WebGL on the same data repeatedly. By your own metric, three.js is less “about” 3d than WebGL. Anyway, none of this really relates to the original point. Saying that WebGL is about data is neither supporting the argument that WebGL is about 2D graphics nor refuting the argument that WebGL is about 3D graphics. > To be clear, I am not saying that OpenGL, Vulkan, etc. should provide scene graphs. Right. They shouldn’t because their purpose is 2D or 3D drawing in any form, not management of a node graph or scheduling of draw calls.
- westoncb 8y ago
  > All of these can be described as being explicitly about collections of data of specific types. This isn’t differentiating, you’re still describing all APIs. Maybe my usage of 'explicit' was unclear. Here is an example of a primitive which is explicitly about storing/moving collections of data, independent of what that data is used for: glBufferData, glClearBufferfv, glGetBufferParameteriv, glMapBufferRange. Firebase and OpenCV I could maybe see having explicit data constructs; Instagram sounds hugely unlikely. And saying that three.js is explicitly about moving data around is ridiculous: it's core is about 3d graphics concepts, like coordinate systems, geometries, materials, and cameras. The only time where it talks about raw data in the same way are a small number of classes that need to be extremely efficient, so they compromise and break the abstraction to WebGL, making reference to its primitives. > Three.js is built on top of WebGL, it doesn’t do 3d graphics without WebGL Not at all true. It's architected to be independent of WebGL. When you use it you can construct a WebGLRenderer or a CanvasRenderer and get 3D graphics with either (obviously WebGLRenderer is going to be far more efficient since it uses the GPU, but it is in no way 'more 3d'). > Saying that WebGL is about data is neither supporting the argument that WebGL is about 2D graphics nor refuting the argument that WebGL is about 3D graphics. I should have clarified the connection: I saw the argument that it's about 2D graphics is being one way of getting at a more significant point: it's not really about 3D graphics as much as people typically think. Which was my shared point.

dahart 8y ago

> OpenGL is different because the primitives in it are explicitly about collections of data of specific types. Different than what? Three.js? OpenCV? Firebase? Instagram? All of these can be described as being explicitly about collections of data of specific types. This isn’t differentiating, you’re still describing all APIs. > Whereas an API that was ‘about’ 3D graphics would offer primitives related to the shape, position, and other aspects of the appearance of 3D forms and how they change in time. That is what WebGL provides. You’re trying to split a hair that doesn’t exist. I realize you’re trying to talk about the difference between immediate mode and retained state graphics APIs. Both are “about” 3D, and retained mode is not more 3D or more “about” 3D than immediate mode. I’d argue the other way around. Three.js is built on top of WebGL, it doesn’t do 3d graphics without WebGL, and the only thing it adds is retained mode state, i.e., a specific type of data. Three.js doesn’t do it’s own drawing, and it doesn’t add any 3D to WebGL that wasn’t already there, it only adds management of some host side memory so it can call WebGL on the same data repeatedly. By your own metric, three.js is less “about” 3d than WebGL. Anyway, none of this really relates to the original point. Saying that WebGL is about data is neither supporting the argument that WebGL is about 2D graphics nor refuting the argument that WebGL is about 3D graphics. > To be clear, I am not saying that OpenGL, Vulkan, etc. should provide scene graphs. Right. They shouldn’t because their purpose is 2D or 3D drawing in any form, not management of a node graph or scheduling of draw calls.

westoncb 8y ago
> All of these can be described as being explicitly about collections of data of specific types. This isn’t differentiating, you’re still describing all APIs. Maybe my usage of 'explicit' was unclear. Here is an example of a primitive which is explicitly about storing/moving collections of data, independent of what that data is used for: glBufferData, glClearBufferfv, glGetBufferParameteriv, glMapBufferRange. Firebase and OpenCV I could maybe see having explicit data constructs; Instagram sounds hugely unlikely. And saying that three.js is explicitly about moving data around is ridiculous: it's core is about 3d graphics concepts, like coordinate systems, geometries, materials, and cameras. The only time where it talks about raw data in the same way are a small number of classes that need to be extremely efficient, so they compromise and break the abstraction to WebGL, making reference to its primitives. > Three.js is built on top of WebGL, it doesn’t do 3d graphics without WebGL Not at all true. It's architected to be independent of WebGL. When you use it you can construct a WebGLRenderer or a CanvasRenderer and get 3D graphics with either (obviously WebGLRenderer is going to be far more efficient since it uses the GPU, but it is in no way 'more 3d'). > Saying that WebGL is about data is neither supporting the argument that WebGL is about 2D graphics nor refuting the argument that WebGL is about 3D graphics. I should have clarified the connection: I saw the argument that it's about 2D graphics is being one way of getting at a more significant point: it's not really about 3D graphics as much as people typically think. Which was my shared point.