its always good to see websites with nice 3d elements involved like this.
started reading the tutorials... and i have to say the quality is questionable. from very big things like the claim that the API is fundamentally 2D (really?) down to small things like doing the pixel space to clip space conversion in an inexperienced way (its one 2d vector multiply or a matrix multiply... surely?)
he is clearly aware of some of this stuff though (he mentions the magic perspective w divide in a later tutorial), so maybe its intended and i am just being over-critical since i understand how this stuff works and disagree with the approach taken to introduce it...
saying that he seems to have confused scene graph with a transform hierarchy. oh dear...
TL;DR OpenGL 1.0 is a 3D library because you can give it 3d data and will draw a 3D with no 3D knowledge on your part. WebGL is not a 3D library because you have supply the 3D knowledge.
Arguably it would have been better to say WebGL is a rasterization library that has some features that make it good for rasterizing 3d. If you think about it though it is, by no reasonable definition, a 3D library.
As for any other issues patches and suggestions welcome.
Greggman, first off, these resources are great, thank you for making them available!
As for the 2d rasterization vs 3d math question, I've bumped into your philosophy online before and never commented but found it did touch a nerve with me as you suggest. I'm not entirely sure why, but its as much an emotional argument as a logical one.
After I thought about it for a while, I concluded that you have a valuable and interesting point. But every time I read it I keep wondering a couple of things, so since you're here I figured I'd just ask.
First, why deny so absolutely that WebGL is 3D? I've been feeling like your point might have more traction with graphics programmers if it left the question open than claim to close the book. Even though you're right, you need to do your own math, WebGL still does accept 3d data, and it does 3d operations on that data. WebGL enables 3d graphics, and denying that it does that is inherently problematic, isn't it? The argument that amount of prior knowledge necessary to use a library should dictate the category of a library also seems pretty subjective to me, and in my experience doesn't generally hold - not many libraries I use are truly black box libraries that don't require prior knowledge. My personal use of OpenGL has always involved me doing a lot of 3d math myself, just like my personal use of OpenCV requires a lot of prior image processing and computer vision knowledge.
Second, why try to convince the internet that WebGL is 2d and not 3d, as opposed to, say, the Khronos Group? If all the official sources of documentation call WebGL a 3d library, then isn't this argument probably going to be futile and never ending?
I can explain why this hits a nerve for me. When I was first learning about 3D rendering (in OpenGL/DirectX) I intuitively thought about the screen space being 2D. I was wrong, and it made me confused about a lot of issues, in particular, I couldn't understand why there must be a near and far clip plane.
The 3D perspective page http://webglfundamentals.org/webgl/lessons/webgl-3d-perspect... clearly describes the rasterization phase as having 3D: the automatic perspective divide and the triangle clipping to a 3D space. Clip space being 3D seems very strange if WebGL is only a 2D API.
My suggested patch would be to rephrase it for the beginner. "WebGL is largely a 3D rasterizing API and not a fire-and-forget scene rendering solution."
If WebGL were only 2D it would be trivial to implement 3D without shaders in <canvas> -- and that is not true, canvas cannot rasterize 3D triangles.
It is called depth testing. There is a depth buffer (or z buffer) which contains the depth value for each pixel. When a pixel is to be written, its depth is calculated and compared the value in depth buffer, if it is closer to camera then it is drawn and value of depth buffer is changed, else the pixel is ignored.
Can you explain why it isn't true? He goes into explicit detail why he thinks it's so, yet you have only repeated "you're wrong" without providing any counter example.
because you can throw 3d data down the pipe naively and it 'just work', it comes out with the same problems as naive use of 2d data - that the transform from world to clip-space becomes the identity matrix, which results in aspect-ratio stretching.
also the idea that old desktop OpenGL is valid any more grates and encourages using it... its something we would like to have died its death 5-10 years ago when it was already out of date.
its also the case that all of the 'desired' functionality for 3d which is 'missing' is equally applicable to 2d and so equally missing from the API. there are no rotations 'out of the box', no aspect ratio correction, no texture mapping, no anything. this is what we expect from a low-level API, the minimum set of features required to make the hardware do the job - not an encyclopaedic library of derivative functionality (this is the place of a higher level library than the hardware interface).
i think the author has confused it being a low-level API with it being 2D. these are not the same. its just as devoid of features regardless as to what space you are rendering in... i can really understand it if coming from a web background where the stack is gigantic and "low-level" is an utterly foreign concept.
(also, in my defence, i didn't go into great detail, since i commented on the post itself to avoid polluting HN with a conversation thread)
OpenGL certainly is a 3D library, but WebGL is based on OpenGL ES (the ES part being important here) and basically just provides facilities to transfer data to/from the GPU and run vertex and pixel shaders.
It is completely up to the user whether the position data for the triangles is given in 2D coordinates from the start or in 3D coordinates and then transformed to 2D coordinates in the vertex shader.
The fact that it makes it fast to do the math for 3D, does not make it a 3D API.
my issue is more with the specific criteria the author uses being invalid. there is no special 2d functionality, e.g. aspect ratio correction or rotations. there is special 3d functionality, and contrary to the authors claim, you can just throw 3d data down the pipe and have it work. you just have a fixed, non-aspect-ratio-corrected view, the same as you get when you naively throw 2d data down the pipeline.
also, please don't confuse OpenGL circa 1999 with modern OpenGL. the features removed in ES were considered bad practice 10-15 years ago... i do disagree with removing default shaders (our beautiful flexibility is now relegated to mere boilerplate) but i'm sure the OpenGL ARB had a good reason behind that choice (reducing driver responsibility, reducing points of failure etc.).
also, what is never up to the user is the perspective divide. if a naive user is not aware of this particular, very 3D specific gem, of the hardware/API then he will end up with subtle bugs and maybe even struggle to fix them due to the incomplete knowledge...
i think i came to the conclusion of 0x5f375a84 at the end of that article. at least by the criteria the test program used to measure error.
the differences are tiny though, and there are other measures that can be used (which will result in different constants)
in any case, on most modern hardware it is not relevant since there is some lookup based instruction that is more accurate, and faster.
the problems here aren't enormous, a smart programmer will work them out for himself, but they are misleading. i think there is some confusion just because this is a low-level API, essentially a hardware abstraction layer, but the user is expecting high level features like a complete maths library. (maybe?)
Your terminology and reasoning are very mixed up here. Your argument that "WebGL is not a 3D library because you have supply the 3D knowledge" is complete nonsense.
For one thing, WebGL is not a userland "library", it's an API layer on top of device driver implementations of the OpenGL spec. It's not designed to be something that "makes 3D easy"; it's not even a "library" in the npm/jQuery sense of the word.
I would not recommend any tutorials written by an author whose reasoning about OpenGL is so fundamentally flawed. You should really re-think what you're claiming here.
started reading the tutorials... and i have to say the quality is questionable. from very big things like the claim that the API is fundamentally 2D (really?) down to small things like doing the pixel space to clip space conversion in an inexperienced way (its one 2d vector multiply or a matrix multiply... surely?)
he is clearly aware of some of this stuff though (he mentions the magic perspective w divide in a later tutorial), so maybe its intended and i am just being over-critical since i understand how this stuff works and disagree with the approach taken to introduce it...
saying that he seems to have confused scene graph with a transform hierarchy. oh dear...