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?

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:

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.

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

Now, the first issue you mention concerns attachment sizes.

So first of all, you can have differently sized attachments for a framebuffer object - however, I won’t do you much good because

Another important factor is the [internal] format of the image attached to an attachment point, hereafter denoted attachment:

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.

Thank you very much for the comprehensive reply. I wasn’t quite sure about mixing different attachments but your implication

ensured me that my assumptions were correct.