Yep ;) I'm working on WebGL*2*. Actually, a question...
does anyone know if multiple-render-targets (MRT) works in WebGL2? I was able to use them on WebGL1 using the WEBGL_draw_buffers extension, but I'm wondering if it currently works in Firefox Nightly WebGL2 (since it's supposed to not be an extension anymore) ? On Tuesday, September 29, 2015 at 2:49:15 PM UTC-4, Floh wrote: > > Oh dang, nevermind, I didn't notice the *2* after WebGL :) > > Am Dienstag, 29. September 2015 20:48:37 UTC+2 schrieb Floh: >> >> In general, even though emscripten tries to make porting GL code easy by >> emulating some features and calls of desktop GL, you can only rely on the >> OpenGLES2 feature set, since this is what WebGL is based on (plus optional >> WebGL extensions defined here: >> https://www.khronos.org/registry/webgl/extensions/) >> >> For instance GL_TEXTURE_WRAP_R is for 3D textures, which are not >> supported on WebGL, and for uncompressed texture formats, you can only use >> a very small subset of what desktop GL allows (see here: >> https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml). >> >> Cheers, >> -Floh. >> >> Am Montag, 28. September 2015 19:54:28 UTC+2 schrieb Robert Goulet: >>> >>> Here's a few issues I've noticed so far with WebGL2 in Firefox Nightly, >>> latest Emscripten : >>> >>> - Creating a texture format GL_RED, GL_RED_INTEGER, GL_RG or >>> GL_RG_INTEGER doesn't error out, but using them for rendering using >>> framebuffers fails (invalid framebuffer operations). >>> - Using GL_TEXTURE_WRAP_R parameter name in glTexParameteri returns >>> invalid enum. >>> >>> On Saturday, September 19, 2015 at 8:30:50 AM UTC-4, Floh wrote: >>>> >>>> You can basically rewrite your example like this and it should work on >>>> desktop GL (not sure if it works in Core Profiles though): >>>> >>>> GLfloat verts_Init[] = { >>>> -1.0f, 0.0f, 0.0f, >>>> 0.0f, 1.0f, 0.0f, >>>> 0.0f, 0.0f, 0.0f }; >>>> glBindBuffer(GL_ARRAY_BUFFER, 0); >>>> glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, verts_Init); >>>> // (x, y, z) for pos >>>> glEnableVertexAttribArray(0); >>>> >>>> This behaviour is a nice example why OpenGL has become so confusing, >>>> because the same functions changed their behaviour over time. Note that >>>> the >>>> function is called glVertexAttrib*Pointer*, and the last attribute is of >>>> type 'const GLvoid*', even though current OpenGL docs say this is actually >>>> an offset, not a pointer ( >>>> https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml). >>>> >>>> If you look at the documentation of older GL version, it talks about >>>> the last parameter being a pointer, not an offset: >>>> http://docs.gl/gl2/glVertexAttribPointer >>>> >>>> The function basically has been retconned into having 2 different >>>> behaviours, the pointer arg is either an offset or a direct pointer, >>>> depending whether a buffer is bound or not. >>>> >>>> Cheers, >>>> -Floh. >>>> >>>> Am Samstag, 19. September 2015 03:26:00 UTC+2 schrieb [email protected] >>>> : >>>>> >>>>> @Floh: Consider this example code: >>>>> >>>>> GLfloat verts_Init[] = { >>>>> -1.0f, 0.0f, 0.0f, >>>>> 0.0f, 1.0f, 0.0f, >>>>> 0.0f, 0.0f, 0.0f }; >>>>> std::copy(verts_Init, verts_Init + 9, m_verts); >>>>> glBindBuffer(GL_ARRAY_BUFFER, m_idVBO[0]); >>>>> glBufferData(GL_ARRAY_BUFFER, 9*sizeof(GLfloat), m_verts, >>>>> GL_STATIC_DRAW); >>>>> glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, 0); // (x, >>>>> y, z) for pos >>>>> glEnableVertexAttribArray(0); >>>>> >>>>> I'm calling glVertexAttribPointer() "with an offset into a buffer" >>>>> right? What's an example of calling glVertexAttribPointer() "with an >>>>> actual pointer to the data"? >>>>> >>>>> "don't provide any input geometry to the vertex shader" - interesting. >>>>> I see ( http://bit.ly/1F7vk83 ) shows an example where the vertex >>>>> position is specified inside the vertex shader GLSL code instead of being >>>>> passed in from C++ code. >>>>> >>>>> @jj: I'm glad to hear this is being worked on. I wonder if this has >>>>> any relation to the fact that ANGLE does not yet fully support GLES3 >>>>> since >>>>> ANGLE is used by Chrome? >>>>> >>>>> Anyone know the ETA on when there will be a reasonably robust/stable >>>>> GLES3 support in Emscripten and a reasonably robust/stable WebGL 2 >>>>> browser >>>>> for the Emscripten-generated javascript to run? >>>>> >>>>> --- >>>>> >>>>> On Thursday, September 17, 2015 at 10:52:17 PM UTC-5, >>>>> [email protected] wrote: >>>>>> >>>>>> What is the ETA on OpenGL ES 3.0 support for Emscripten? >>>>>> >>>>>> ( http://bit.ly/1Qjunsp ) says Emscripten supports OpenGL ES 2.0. >>>>>> However, I see no mention of OpenGL ES 3.0? >>>>>> >>>>>> As for OpenGL ES 2.0 support, apparently this means the >>>>>> WebGL-friendly subset of OpenGL + the ability to use glDrawArrays() >>>>>> without >>>>>> a bound buffer. Does "without a bound buffer" mean without calling >>>>>> glBindBuffer()? >>>>>> >>>>>> Why would you want to call glDrawArrays() without first calling >>>>>> glBindBuffer()? Wouldn't that mean to draw nothing? >>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
