Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: Framebuffer depth attachments

  1. #1
    Junior Member Newbie
    Join Date
    Nov 2013
    Posts
    7

    Framebuffer depth attachments

    I have a bit of a problem refactoring my deferred renderer.

    I used two separate FBO: one for rendering the g-buffer and the other one to render the shadow-maps. Now I try to get rid of the second FBO used for shadow-map rendering and use the g-buffer FBO instead. What I do is to attach the according shadow-map as depth-attachment to the g-buffer FBO then disable drawing to any color-attachments using glDrawBuffer( GL_NONE ) and then I just render the geometry. So the question is whether it is valid to have color-attachments with different resolutions and different types from the depth-attachment?

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    Let's dissect this using the OpenGL 4.4 core specification and be prepared, this is a long answer, but it's useful to know this stuff when working with framebuffer objects. For anything that isn't covered here, I refer you to the sections quoted below.

    The first question to as is if an image, is framebuffer-attachable. The question which types of objects are attachable is answered in section 9.2.2. Let's just examine a single, often used case:

    Quote Originally Posted by Section 9.2.2.
    There are several types of framebuffer-attachable images:[..]
    • A single level of a two-dimensional, two-dimensional multisample, or rectangle texture.[..]
    The above covers pretty much any implementation of a G-buffer I know of. Also, directional-lights, pot-lights and even the six-spot-light technique for simulating point-light shadows is covered by the above.

    As you know, you can use various functions to attach the above mentioned types of images. You can check the requirements for attachment functions, e.g. glFramebufferTexture(...), in section 9.2.8. For instance, attaching a single level of a 2D texture to an attachment using

    Code :
    glFramebufferTexture2D(enum target, enum attachment, enum textarget, uint texture, int level)

    mandates that textarget be either TEXTURE_2D, TEXTURE_2D_MULTISAMPLE and so on ...

    Now that we know what and how to attach to the framebuffer object, the question of completeness arises.

    Quote Originally Posted by Section 9.4
    A framebuffer object is said to be framebuffer complete if all of its attached images, and all framebuffer parameters required to utilize the framebuffer for rendering and reading, are consistently defined and meet the requirements defined below. The rules of framebuffer completeness are dependent on the properties of the attached images, and on certain implementation-dependent restrictions.
    Ergo, if you have only a single attachment which isn't complete, the whole framebuffer is incomplete.

    The important thing is, the call to an attachment function may succeed, but the implications for completeness stem from the properties of the attached image and you will not get an error for attaching a texture object which makes the attachment incomplete. However

    Quote Originally Posted by Section 9.4.4
    An INVALID_FRAMEBUFFER_OPERATION error is generated by attempts to render to or read from a framebuffer which is not framebuffer complete.
    Now, the first issue you mention concerns attachment sizes.

    Quote Originally Posted by Section 9.2
    If the attachment sizes are not all identical, rendering will be limited to the largest area that can fit in all of the attachments (an intersection of rectangles having a lower left of (0, 0) and an upper right of (width, height) for each attachment).
    So first of all, you can have differently sized attachments for a framebuffer object - however, I won't do you much good because

    Quote Originally Posted by Section 9.2
    If the attachment sizes are not all identical, the values of pixels outside the common intersection area after rendering are undefined.
    Another important factor is the [internal] format of the image attached to an attachment point, hereafter denoted attachment:

    Quote Originally Posted by Section 9.4.1
    • If attachment is COLOR_ATTACHMENTi, then image must have a color-renderable internal format.
    • If attachment is DEPTH_ATTACHMENT, then image must have a depth-renderable internal format.
    • If attachment is STENCIL_ATTACHMENT, then image must have a stencil-renderable internal format.
    Color-, depth- and stencil-renderable formats are defined in tables 8.12 and 8.13 of the aforementioned spec. Your usual suspects are RED, RG, RGB or RGBA and the sized internal formats marked "CR" (color-renderable). For depth buffers, DEPTH_COMPONENT or sized internal formats with base internal format DEPTH_COMPONENT are depth-renderable and so forth.

    What follows from the above is the answer to your question: a single attachment has to be complete - independent of any other attachment. Thus, having attachments that differ in various ways is fine, as long as completeness is still given for any of the attachments.

    Feel free to ask further questions and post more detail problems and code if you like.

  3. #3
    Junior Member Newbie
    Join Date
    Nov 2013
    Posts
    7
    Thank you very much for the comprehensive reply. I wasn't quite sure about mixing different attachments but your implication

    Quote Originally Posted by thokra View Post
    What follows from the above is the answer to your question: a single attachment has to be complete - independent of any other attachment. Thus, having attachments that differ in various ways is fine, as long as completeness is still given for any of the attachments.
    ensured me that my assumptions were correct.

Posting Permissions

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