At last i have been able to play around with FBOs. A few questions came up, that i was not able to solve by reading the specs. I might just have missed it in the spec, because i was not motivated to actually read all of the specification, but through searching alone i didn’t find anything.
Here goes:
How do i actually detach a renderable (buffer / texture) from a framebuffer? AFAIK i can do that by “attaching” index 0, but then my code, that is supposed to handle ALL cases looks like this:
//detach any possible renderable…
glFramebufferRenderbufferEXT (GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT + i, GL_RENDERBUFFER_EXT, 0);
glFramebufferTexture1DEXT (GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT + i, GL_TEXTURE_1D, 0, 0);
glFramebufferTexture2DEXT (GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT + i, GL_TEXTURE_2D, 0, 0);
glFramebufferTexture3DEXT (GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT + i, GL_TEXTURE_3D, 0, 0, 0);
And i am not sure, if i need to consider mipmap-levels, 3D slices, etc. too.
I like to use MRT too. There is an example in the FBO spec, but the Drawbuffers spec seems not to be up to date for the FBO case. Can anyone tell me how and when to properly use glDrawBuffer and glDrawBuffers (notice the ‘s’).
maybe unbinding the fbo will detach the render targets automatically?
glDrawBuffer() specifies the buffer you are rendering to usually ( BACK or FRONT, LEFT or RIGHT etc) Usually this is GL_BACK for doublebuffering.
glDrawBuffers() specifies a list of render targets to write to from a fragment shader. gl_FragData[0] is the first in the buffer list gl_FragData[1] the second etc…
These buffers can also be the color attachments of an fbo. The fragmentshader needs glDrawBuffers() to know which buffers to write to.
How do i actually detach a renderable (buffer / texture) from a framebuffer?
Only one of those kinds of attachments can be bound to a particular attachment point at any one time. So it doesn’t matter what kind of renderable you bind with index 0; it will unbind whatever was there.
Originally posted by Overmind: The texture index 0 may specify a valid texture object. To unbind, you have to bind the renderbuffer index 0…
This is not true. Calling any of the attach functions with the name zero detaches what was perviously there, regardless of what was previously attached there. It is not possible to attach one of the “default textures”, the per-context texture objects with name zero, to an FBO.
See the EXT_framebuffer_object spec section that defines the behavior of FramebufferTexture* and FramebufferRenderbuffer.
[QUOTE]
In all three routines, if <texture> is zero, then <textarget>,
<level>, and <zoffset> are ignored.
…
Calling FramebufferTexture{1D|2D|3D}EXT with <texture> name zero
will detach the image identified by <attachment>, if any, in the
framebuffer currently bound to <target>. All state values of the
attachment point specified by <attachment> are set to their default
values listed in table 5.nnn.
[QUOTE]
Also see issues 22 and 31-33 for a discussion of why it was done this way.
Originally posted by Jan: 2) I like to use MRT too. There is an example in the FBO spec, but the Drawbuffers spec seems not to be up to date for the FBO case. Can anyone tell me how and when to properly use glDrawBuffer and glDrawBuffers (notice the ‘s’).
The FBO spec modifies the drawbuffers spec. In the FBO spec, see the section that begins
The command
void DrawBuffers( sizei n, const enum *bufs );
Basically, the attachment names have been added to the list of values that you can pass to DrawBuffers. You might find it instructional to diff this block against the equivalent block in the OpenGL-2.0 specification.
See issue 53 for a discussion of how/why the draw buffers “indirection table” is useful while bound to an FBO. Motivating example usage includes a multi-pass algorighm that, each pass, ping-pongs which of the two color attachments is the texture (source) and which is the render target (destination).
