I’m trying to get up and running with FBOs, and I’m uncertain about how the attachments work.
My application will have many (hundreds) of 2D textures, but only 3-6 will be active at any given time (depending on whether or not I can take advantage of multitexturing). I’d like to use just one FBO in my app.
Is it possible to reuse an attachment point once a texture is bound to it?
In my first experimetal app, I used glFramebufferTexture2DEXT to bind a texture to the framebuffer at GL_COLOR_ATTACHMENT0_EXT, so I could write to the texture. I immediately performed the same action to write to a second texture. I noticed that binding the second texture to GL_COLOR_ATTACHMENT0_EXT caused glCheckFramebufferStatusEXT to complain.
My original assumption was that binding two textures to the same attachment would cause the first texture to be unattached. Is this not the case? Is there a way to reuse the attachment for a different texture?
Thanks!
You should be able to bind a different texture.
Actually that’s the recommended usage of FBOs. When the textures have the same format, you should only use one FBO and rebind textures only.
Are the textures the same format? Shouldn’t really matter, but you never know 
Or more important, are they the same size? If not, you propably have to rebind the depth buffer, too, to match the new size.
Yes, the textures are definitely of the same size and format…
I’ll try to simplify the test project even further and see if there’s something more…
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.
So, you have to call glFramebufferTexture2D with a zero in the texture argument to detach the current texture before binding another texture.
[edit] although the samples in the specification don’t seem to do that - they just keep binding new textures.
Are you sure the framebufferstatus is a bad value? There are some status values reported that are just information rather than errors.
Hmm… Never looked at it like this. I always thought that this passage in the spec means “if you explicitly want to get rid of one attachment, bind it to zero”, with the implicit assumption that binding another texture over the last one just works naturally.
It’s not easy to formulate something careful enough such that only one valid interpretation is possible .
Well, I just tried building a slightly simpler example to try to reproduce the problem. This time, I’m not getting any errors from the framebuffer. I must have been doing something else incorrectly.
However, I’m glad that this confusion has been cleared up for me; otherwise, I’d be wondering about this everytime I ran into a new problem.