glFramebufferTexture2DEXT clears textures; can't use them later on?

OpenGL Development
#1

I’m trying to use the results of an fbo as input to a shader. However, it appears when I switch the attachments to the FBO, the original attachments get cleared.

I want to use the same FBO because I hear it is faster to switch textures than to switch FBOs.

So, I setup my FBO with two textures:

gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, GL.GL_COLOR_ATTACHMENT0_EXT, GL.GL_TEXTURE_2D, ftexture[0], 0);
…
gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, GL.GL_DEPTH_ATTACHMENT_EXT, GL.GL_TEXTURE_2D, fdepthtexture[0], 0);

And everything renders properly, until I want to attach two different textures to the FBO, and use the original textures as inputs for the fragment shader.

For example, this clears the original texture, when i try to unattach the texture:
gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, GL.GL_COLOR_ATTACHMENT0_EXT, GL.GL_TEXTURE_2D, 0, 0);

Or, this clears the original texture, when I try to attach another texture to the FBO (even without the line above):
gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, GL.GL_COLOR_ATTACHMENT0_EXT, GL.GL_TEXTURE_2D, anothertexure[0], 0);

So, is it not possible to attach different textures to an FBO and pass the orignals as inputs to a fragment shader?

#2

Can you write a simple test case. I have not heard of this behavior before and I’m wondering if it’s a driver bug. I would like to try it on my computer.

Also, I’m curious where you heard switching textures on an FBO is faster than binding a new FBO. I would think that the validation and completeness checking when a texture is attached to an FBO would be much slower than calling glBindFramebuffer().

#3

I have switched to using 2 FBOs to avoid this clearing problem.

The place I read the bit about the faster switching was here:
“Switching framebuffer-attachable images is much faster than switching between FBOs” (http://www.songho.ca/opengl/gl_fbo.html).

I guess in general, what is the method for calling several shaders on the some textures to do some special processing? Is this not a common practice to render to FBO textures, then pass these as input to fragment shaders, and output to other textures (multiple render targets) and continue this cylce until a final output texture is created? Is my overall strategy flawed?

#4

There is no clearing being done when you attach or remove textures from an FBO. I’m pretty sure you’re doing something wrong, or it could even be a driver bug.
In some cases there’s a huge difference in performance between changing an attachment and binding a different FBO. My old 7900 GTX got huge (several times) speedup by doing this, but my GTX 295 (and my current laptop’s GTX 460M) didn’t get much of a speedup. It’s either better drivers or (more likely) more CPU power that fixed it. Anyway, changing attachments is faster, especially on older computers.

Some points:

  • You can’t have different sizes of textures/renderbuffers attached to the same FBO (but this should crash though).
  • Everytime you start rendering to something with a different resolution (e.g. bind FBOs with a different size than the screen backbuffer or the previous FBO), be sure to set the viewport correctly with glViewport!!! The same might apply for your matrices too if they rely on the size of the render target.
  • You can’t render to and read from the same texture! This will NOT crash. It might work on some cards/drivers, but mostly you just end up with garbage on the screen, or a black screen.
  • Texture filtering settings? Maybe the texture is incomplete because it doesn’t have mipmaps and mipmap filtering is enabled?
  • Shaders: Have you setup your texture samplers properly (bound them with glUniform)?
  • Did you remember to bind the FBO before trying to set its attachments? =S

Can’t think of much more ATM. You should make a simpler test, as the error could be anywhere (including the driver xd). You could also post some more code. =)