Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>WebGL is actually a 2D API, not a 3D API. What does it mean?</p> </blockquote> <p>It means you should stop listening to whatever website or person told you that. When people say idiotic things like that, it's best to ignore them and move on to more reasonable tutorials/information/discussions.</p> <p>You can certainly work with WebGL in purely 2D terms. You can pass 2D positions to vertex shaders. You can turn off depth testing entirely. And so forth. But the output from your vertex shader is a <a href="http://en.wikipedia.org/wiki/Homogeneous_coordinates">4D homogeneous coordinate</a>, even if your W is 1 and your Z is 0. So the rendering system is going to do all of the 3D math that it would normally do for a 3D scene.</p> <p>Yes, rasterization is basically a 2D process, with depth testing as a "hack" to allow for hidden surface removal. But this has been true of <em>all</em> rasterization-based renders. D3D, OpenGL, GLIDE, and every software rasterizer would <em>also</em> be "2D API"s by this logic.</p> <p>And if all of them are 2D APIs, then the statement is pointless. It puts OpenGL/D3D on the same level as <em>actual</em> "2D API"s like SDL and Direct2D. Yet those "2D API"s can't do 3D rendering at all (or not without substantial pain).</p> <p>So the statement is both factually incorrect and incredibly misleading. Whoever said it is not worth your time or attention.</p> <blockquote> <p>from comments:</p> </blockquote> <p>The person who originally wrote this "WebGL is 2D" stuff has deigned to explain his reasoning, so I'll address those points here.</p> <p>Let's use his definition of API dimensionality. His exact quote is:</p> <blockquote> <p>You gave them 3D data and nothing else and they gave you a 3D display. OpenGL ES 2.0 is a 2D api. You have to supply all of the 3D to 2D math conversion yourself.</p> </blockquote> <p>From this, we can deduce that a "3D API" means "an API which 'you' feed 3D values into to cause 3D rendering to happen." Similarly, a "2D API" means "an API which 'you' feed 2D values into to cause 2D rendering to happen."</p> <p>Let's assume that 'you' doesn't simply mean the dimensionality of the values fetched from a buffer object. 'You' means every piece of code you have direct control over, which includes your shader. OK, fine. So 'you', for WebGL, stops at the end of the vertex shader. Therefore, WebGL starts doing its stuff with the vertex shader outputs.</p> <p>The output from a vertex shader is a 4D homogeneous coordinate. I'm guessing that the argument is that a 4D homogeneous coordinate is somehow identical to a 2D coordinate. Even though it's obviously not, since it has 2 more components, and the various math operations you do with them are very different.</p> <p>I'll let you decide whether you want to consider a 4D homogeneous coordinate to be identical to a 2D coordinate.</p> <p>Instead, I'll look at how <em>WebGL</em> treats the 4D output. Does it convert it into a 2D coordinate? The OpenGL specification says no.</p> <p>From <a href="http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf">the OpenGL ES 2.0</a>, section 2.12, folio page 44:</p> <blockquote> <p>Vertex shader execution yields a vertex coordinate <code>gl_Position</code> which is assumed to be in clip coordinates. Perspective division is carried out on clip coordinates to yield normalized device coordinates, followed by a viewport transformation to convert these coordinates into window coordinates (see figure 2.4).</p> <p>Clip coordinates are four-dimensional homogeneous vectors consisting of x, y, z, and w coordinates (in that order). If a vertex’s clip coordinates are:</p> <p>(x<sub>c</sub>, y<sub>c</sub>, z<sub>c</sub>, w<sub>c</sub>)</p> <p>then the vertex’s normalized device coordinates are</p> <p>(x<sub>d</sub>, y<sub>d</sub>, z<sub>d</sub>) = (x<sub>c</sub>/w<sub>c</sub>, y<sub>c</sub>/, z<sub>c</sub>/w<sub>c</sub>)</p> </blockquote> <p>Normalized device coordinate space has 3 components. It is therefore not a 2D space. But what about later transformations?</p> <p>Well, from section 2.12.1 of the same specification (folio pages 44-45):</p> <blockquote> <p>The viewport transformation is determined by the viewport’s width and height in pixels, p<sub>x</sub> and p<sub>y</sub>, respectively, and its center (o<sub>x</sub>, o<sub>y</sub>) (also in pixels). The vertex’s window coordinates, (x<sub>w</sub>, y<sub>w</sub>, z<sub>w</sub>), are given by</p> <p>x<sub>w</sub> = (p<sub>x</sub>/2)x<sub>d</sub> + o<sub>x</sub></p> <p>y<sub>w</sub> = (p<sub>y</sub>/2)y<sub>d</sub> + o<sub>y</sub></p> <p>z<sub>w</sub> = ((f - n)/2)z<sub>d</sub> + (n + f)/2</p> </blockquote> <p>So yes, even <em>window space</em> is a 3D coordinate system. Window space is the final space that OpenGL uses in its computation; window space goes straight to the rasterizer. That's what gets rendered.</p> <p>Therefore, <em>by the OpenGL ES 2.0 specification</em>, there is no point in the entire rendering pipeline where anything get converted into a <em>purely</em> 2D space.</p> <p>WebGL is an API that you feed 4D homogeneous coordinates into. At no point does WebGL perform any "3D to 2D math conversion", nor does the user. Nobody converts anything into 2D coordinates at any point in WebGL. 2D values are not fed through a 2D pipeline; 4D values are fed through a 3D pipeline.</p> <p>Therefore, <em>by his own definition</em>, WebGL is not a 2D API.</p> <p>QED.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload