PDA

View Full Version : Framebuffer depth attachments



Jnanadeva
12-16-2013, 01:31 PM
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?

thokra
12-17-2013, 07:06 AM
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:


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


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.


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


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.


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


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:




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.

Jnanadeva
12-21-2013, 01:25 AM
Thank you very much for the comprehensive reply. I wasn't quite sure about mixing different attachments but your implication


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.