MRT should work correctly in WebGL 2. There are some very recent changes I did in structuring the access to those entry points with the webgl2 pull requests, so you could try the latest Emscripten incoming to see if it works there.
As for the other errors, if you can make small test cases, I can help push attention to Firefox bugzilla and make sure they get some eyes from the graphics team. Cheers, Jukka 2015-09-29 11:53 GMT-07:00 Robert Goulet <[email protected]>: > 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. > -- 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.
