Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Saving Depth Buffer to Texture

  1. #11
    Junior Member Newbie
    Join Date
    Apr 2011
    Location
    USA
    Posts
    17
    All of the shaders that I am calling while the FBO is active are writing to location 1, however, the texture doesn't seem to change. I tried even revering the texture back to RGB8 form, and am writing vec3(0.5,0.5,0.5) to it in both shaders, yet it still displays 1.0,1.0,1.0. I think the bindings are correct:
    Code :
           glActiveTexture(GL_TEXTURE0);
        // ----- THE DEPTH TEXTURE --------
        glGenTextures(1, &depthTextureId);
        glBindTexture(GL_TEXTURE_2D, depthTextureId);
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 1024, 780, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
     
        // ------ THE RENDER TEXTURE ------
        glGenTextures(1, &renderTex);
        glBindTexture(GL_TEXTURE_2D, renderTex);
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 1024 /*512*/, 780/*512*/, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
     
        // ---- setup the FBO ------
        // Create a frame buffer
        glGenFramebuffers(1, &fboHandle);
        glBindFramebuffer(GL_FRAMEBUFFER, fboHandle);
     
        // create the depth buffer
        glGenRenderbuffers(1, &rboId);
        glBindRenderbuffer(GL_RENDERBUFFER, rboId);
        glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT24, 1024, 780); //512, 512);
        glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, rboId);
     
     
        glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, renderTex, 0);
        glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT1, GL_TEXTURE_2D, depthTextureId, 0);
     
     
     
        GLenum drawBuffs[] = {GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1}; 
        glDrawBuffers(2, drawBuffs);
    Any ideas as to why the FBO would be writing to color attachment 0, and not color attachment 1 as well (checked with gdebugger)? Does something specifically need to be enabled to allow for multiple color attachments?

  2. #12
    Junior Member Newbie
    Join Date
    Apr 2011
    Location
    USA
    Posts
    17
    I found the issue. The shader correctly writes to the second texture if I set it to be RGBA as well (RGBA, RGBA8, RGBAF32, RGBF16, etc.). With that said, is this a requirements with FBOs, where all of the GL_COLOR_ATTACHMENTs must be of the same color type?

  3. #13
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    They certainly don't have to be the same type - mine aren't - but maybe they have to be vec4?

  4. #14
    Junior Member Newbie
    Join Date
    Apr 2011
    Location
    USA
    Posts
    17
    It seems that you are correct. I changed both the vec tags and the color type at the same time, and I had seen an example fragment shader mixing vec3 and vec4 (a deferred shader which used vec4 for the fragment output, and vec3 for the FBO bindings). With that said, I guess the stipulation is that the layout slots corresponding to the FBO bindings must either all be vec3 or all be vec4?

    Thanks for the help, everything seems to work now.

  5. #15
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    I wonder if some other people can comment on valid combinations of FBO attachments

  6. #16
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    76
    From the Gl4.1 spec, sec. 4.4:
    All attachments must have the same layering (1d, 2d, 3d texture, cubemap...), the same sample number and the vague restriction

    "The combination of internal formats of the attached images does not violate
    an implementation-dependent set of restrictions."

    Concluding from the first two i would bet that the format dimensionality (vec4, vec3,...) also is a restriction for most drivers.

    However, the fbo should report FRAMEBUFFER_UNSUPPORTED in this case... did you check this?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •