View Full Version : FBO and changing the colour attachment

05-15-2010, 04:09 PM
Hey there,

Here's a quick question. I'm not a noob in OpenGL as such, but I'm currently working with FBOs for the first time (yeah, I never had to use them before) and I'm having a bit of a headache. So, what I want to do is:

1) render the 3D part of the scene to texture
2) render the 2D part to a different texture
3) composite the parts with some effects, overlays etc. and dump it to the screen.

Since all the textures I need are the same dimensions, I thought I could get away with just 1 FBO and just go changing the colour attachment to as needed (as opposed to multiple FBOs, one for each target texture), but apparently this isn't working - only the very first frame of the first colour attachment is drawn, which results in a static image being displayed. Am I doing something wrong, or is changing the colour attachment wrong conceptually and I can't avoid multiple FBOs?

05-15-2010, 04:38 PM
This is a good question. After reading the framebuffer_object description I couldn't really determine if doing it this way is good or bad (as opposed to just maintaining multiple FBO objects). The only thing I could find is in section 4.4.2

Because of the <implementation-dependent> clause of the framebuffer completeness test in particular, and because framebuffer completeness can change when the set of attached images is modified, it is strongly advised, though is not required, that an application check to see if the framebuffer is complete prior to rendering. The status of the framebuffer object currently bound to <target> can be queried by calling

enum CheckFramebufferStatus(enum target);

<target> must be DRAW_FRAMEBUFFER, READ_FRAMEBUFFER or FRAMEBUFFER. FRAMEBUFFER is equivalent to DRAW_FRAMEBUFFER. If CheckFramebufferStatus is called within a Begin/End pair, an INVALID_OPERATION error is generated. If CheckFramebufferStatus generates an error, 0 is returned.

Due to the reflection required for correctness checking, I always assumed that this would be slower than just using multiple FBOs.
There also has to be some pipeline synchronization required by doing it this way as well that "may" not be necessary with multiple FBOs.

FWIW, I frequently use multiple FBO objects. This is mainly due to the convenience of just setting them active and rendering. I would also be interested in knowing definitively if multiple FBOs are desirable vs changing state within a single FBO.