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

Re: [Public WebGL] The state of MRTs

On Wed, Mar 21, 2012 at 12:57 AM, Gregg Tavares (å) <gman@google.com> wrote:
I'm not following. Sorry. draw_buffers deals with backbuffers, not with framebuffers. I'm not proposing adding more drawbuffers. drawbuffers are a very different topic which a much larger API and therefore much more complicated to spec out.Â

Yeah the specifications are much more complicated because of the legacy drawing buffers. But they also introduced the gl_FragData[N] mechanism to OpenGL. So what is the canonical direction that OES is taking with the naming and scope? Is there going to be some nice and tidy specification just for MRT?
I don't know where that idea came from. OES_texture_float, WEBGL_comressed_texture_s3tc both add enumerants only. This proposal is no different.
OES_texture_float adds no symbol whatsoever (empty IDL) because it uses the enumerants already present.
WEBGL_compressed_texture_s3tc does not add enumerants to the context, but to the extension object. The naming is also postfixed with _EXT. So the correct example would be:

gl.framebufferTexture2D(gl.FRAMEBUFFER, mrt_extension_object.COLOR_ATTACHMENT6_EXT, gl.TEXTURE_2D, sometexture, 0);