[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 (勤) <firstname.lastname@example.org> 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);
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.