Indeed, MRT works well, before and after your changes. I wasn't sure because it wasn't working in our game engine until I found the mistake. I'll try to prepare a small test case for the other issues.
On Sunday, October 4, 2015 at 2:41:11 PM UTC-4, jj wrote: > > 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] > <javascript:>>: > >> 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] <javascript:>. >> 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.
