Hacker News new | past | comments | ask | show | jobs | submit login

I like how it starts by mentioning that WebGL, fundamentally, is 2D, and shaders are where all the 3D magic happens. It's true, and it's important for understanding it.



His notion of a "2d" library versus a "3d" library is weird. First, who cares? He's inventing this semantic argument that nobody else has even bothered with.

Second, WebGL has builtin depth buffers, vertices are specified with 3+ coordinates, and most of the shader math operates on things obviously in three dimensions... so, saying it's 2D is incredibly misleading.


The person that cares is the the person that expects a library called something to actually do what it says. If I download a physics library I expect to to do the physics, not just be a math library with some features that happen to help you write your own physics library.

If I download a png library I expect it to decode and/or encode PNGs not just be a zlib library and some pointers to some docs on the png format.

WebGL is not a 3D library by any possible definition as it does not provide 3D. It's a rasterization at best.

Why does that matter? Because if you want a 3D library, as in a library that does 3D then you want something else like three.js, (http://threejs.org). Knowing that WebGL is not a 3D library and that you're going to have to write your own from scratch if you use it directly seems like an important distinction


Clip space is in 3d. You have a depth buffer and three coordinates. There's no way around that: it's 3d.

What you're saying is "3d" is just utility functions to transform something into clip space. The reason they got rid of those in OpenGL ES (and WebGL is based on ES) is that most of it was useless outside of demos. pushMatrix/popMatrix/translate/rotate/scale are simple to use, but as soon as you need to do something like interpolate a camera between two rotations you end up doing your own vector math and using glLoadMatrix anyway.


three.js is a 3D engine. WebGL is a library that let's you interface with 3D graphic accelerators(rasterizers on steroids). That is it's main purpose. Rasterization is a fundamental of real-time 3D graphics. I am not sure why people are feeling deceived by finding this out?


Its a distinction, not a deception. If I'm going to write a game and I hear about WebGL, I have to make the distinction between where my art gets turned into an asset, and where that asset gets rendered. There is a lot of ground between those two points, and understanding the difference between a library that you can just throw artwork at, and a device-driver layer that expects data in a certain format (or it won't work at all), is where the application/engine/library lines must be drawn in the sand.

The author is (imho) correct in pointing this out from the perspective of having produced a tutorial for newcomers to this scene - so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better. That may well be the case, but use the rear-vision mirror and look at this from a total newbie perspective. You can't just load up Wavefront .obj's into a WebGL instance and expect to get a bouncing ball. You'll need a 3D engine - or library - to do that. There's room in this discussion to fill that void - for the newbie - by using terminology that allows a better understanding than, perhaps, those who understand it all, already, permit/allow/agree to.

The distinction seems to have a locus around the data formats - either of the files being loaded, or at the parameter/buffer-object layer. There is quite some territory between an .OBJ vector (for example) and some other vector format that needs to be loaded into buffers and passed over to the hardware device through a driver layer. Where does the physics go? What is a shader for and why bother with it in this context? These questions get answered by having firm terminology: WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on .. and it may well be an engine which uses WebGL simply as one of a series of front-ends, through a driver layer, successfully too - they're out there.


> so far my observation is that those who wish to argue with him about this point seem to want to generalize it into a ball of mystery, as they are more expert and know the territory better.

It's the opposite, this stuff is already hard, there's no need to make it more complicated by introducing a distinction that's misleading.

> WebGL is not a 3D library, because a 3D library would have some sort of blackbox'ed object loader, maybe a bit of physics/collision-detection too, and so on ..

That's a pretty arbitrary cutoff, but all the same: you're describing a 3d engine, not a library. Besides why would you want all that in one library? I'd rather have my mesh loading and my physics be separate libraries so I can have more choices and keep my includes small.


In one sense, WebGL is a 4D library, since most vertex and color buffers are vec4s. In another sense, WebGL is 3D, since the vertices (and colors, if you're using premultiplied alpha: http://core.ac.uk/download/pdf/1578955.pdf) are in 3-dimensional projective space. In another sense, WebGL is a 2D library, since it's outputting 2D fragments.

The author is just making it clear that there's no magic here. It's all just 2D points on a screen eventually.


The folks who consider WebGL as a 2D API include some of the the browser developers who implemented it. That said, I don't fully agree with them. If WebGL were simply a 2D API, this example, from a talk I gave way back in '13 wouldn't work. In this example, one triangle is clearly drawn behind the other using only raw 3D coordinates with no projection yet.

http://www.vizitsolutions.com/portfolio/webgl/animatedWalkth...

It also isn't a fully 3D API either, otherwise we wouldn't have to be so concerned about the order in which we draw transparent objects. This is the result of using a 2D drawing surface plus a depth buffer.

That said, it might be too subtle a point to open with. Especially since you are showing code, the understanding of which requires material that they haven't covered yet.


OpenGL is a collection of api calls that move buffer data around. It is an api for interacting with shaders compiled into a program. This is all done in 2D, 3D, and even 4D. The rendered product is a screen which only has 2 dimensions, but calling it 2D is a huge oversimplification.


its not exactly accurate or relevant. clip space is 2d because the monitor is.

all of the 3d operations and 3d relevant functionality breaks the argument. the depth buffer for instance, and even more so, the perspective transformation hack (1/w) have limited utility outside of 3D...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: