[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] The state of MRTs



On Tue, Mar 20, 2012 at 10:59 PM, Gregg Tavares (å) <gman@google.com> wrote:
How it's emulated is relevant as long as it works no?Â
It's not. You missed the gist of the message. the name draw_buffers is the right name. I think fbo_color_attachment_foo is something nvidia made up. They've since introduced NV_draw_buffers, which at least indicates that OES intends to follow the ARB naming scheme for the functionality. I would think it best not to follow one vendors lone example in naming.
Â
Âgl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT7, gl.RENDERBUFFER, somerenderbuffer);
Âgl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT6, gl.TEXTURE_2D, sometexture, 0);
What new API is needed?
You're right, got confused there.

Nevertheless it has been the practise that enumerants are introduced by extensions on the extension object and do not extend the webgl context. gl.COLOR_ATTACHMENT1 and so forth does not exist in the webgl context. You're either gonna break that principle or derive the enumerants from the extension object.
Â
I don't think that's possible. Each draw call may effect depth and stencil buffers and so the next call would not do the same thing as the previous.
Right, bummer. Still a way to gracefully fall back without too much hassle would be nice. You surely must realize that it's kinda tedious to keep a shader around that uses gl_FragData[N] and then keep N other shaders around one intended to be used for each pass, and have them be maintained/changed in sync.