frame buffer objects and depth values

I am rendering a scene with an FBO. I have a simple object, a cube, being rendered with immediate mode. I have a shader that colors the faces of my cube based on surface normals. The resulting scene shows faces that should have been omitted. For example, when coloring the cube’s face that points down OpenGL’s x-axis, I render a red color. However, from my camera’s (perspective) point-of-view, this face should not be visible, because the cube face that points out the z-axis should occlude it. I am using the shader to color the front face blue, and the right face red. With my camera view, I expected only to see the front (blue) face, but part of the right (red) face is actually overwriting the front face. I assumed this is a depth problem, would anyone confirm this please?

Assuming the reason my shader overwrites part of the front-face with the right-face is because I don’t have proper depth values available for the Depth Test feature, I attached a render buffer object to the depth attachment. This caused strange results, my color attachments were not written and remained black (the clear color). So, I am now wondering, do I even need the depth attachment, or did I attach it incorrectly? Maybe the depth attachment image data was formated incorrectly, what should the render buffer image data be set to?


From what you say it seems to be a depth problem, at least from your first paragraph.

You can attach a depth RBO to your FBO. But you’ll also need a color RBO in the same FBO if you want to see things.

Did you ensured your FBO has been validated before using it ?
Also did you enabled depth test ?

If all of that is correct, then pertinent pieces of code would be of help.

Hi Jide,
Thanks for confirming that I have a depth issue. Do you know if one must explicitly add a depth buffer attachment when rendering to an FBO? I only added my RBO (depth attachment) hoping it would fix my depth problems, but it didn’t change anything. Here is a screenshot of what I’m talking about. You can see the normals for 3 faces (I’m only drawing 3 faces of my cube at the moment). The right-facing surface (red) should be occluded by the front-facing quad (blue). I have shown this image via a 2D texture object (color attachment 0).

I enabled depth test via:

I validated my FBO with:

 GLenum result = glCheckFramebufferStatusEXT( GL_FRAMEBUFFER_EXT );
 switch( result )
     std::cout << "fbo: ok." << std::endl;
   } break;

  blah blah blah

I am setting the image data for my color attachment via:

                _image->GetData() );  // same as NULL

And the image data for the RBO via:

                            img.GetHeight() );

Thanks for any more suggestions.

This is a depth issue, noticeable from your shot.

Also, I advise you to deeply read the FBO specs here:

Now, I wonder what you want to do: do you want to render to a texture or do you want to render to a buffer ?

You should add a depth RBO attachment to your FBO.
Finally, ensure your RBOs are well generated, bound and so.

I would like to render the color to a texture, I don’t really care how the depth information is preserved, whether it be automatically, or my own attachment.

Thanks for showing me that I need to attach a depth RBO. I’m reading through the extension description now. Maybe the depth attachment needs to be the first attachment? The RBO looks valid. It has a valid id, and I bind it when assigning the image data. Also, I bind the FBO when attaching the depth RBO. I hope to find this problem soon! Thanks for your help.

Well, I found out that I do have an error:
“GL ERROR - Function glRenderbufferStorageEXT generated error GL_INVALID_ENUM”

I’m not sure what value to try with the storage function. I’ve tried several. Currently using:

void OpenGLRenderBuffer::SetImageDimensions(const Image& img) const
                            img.GetHeight() );

This example comes from the extension specs…so I had hoped it would work.

Do you know how I can fix this error?

Give more pieces of code so that I can see the whole process: it will definately be more easy. Do you generate your RBO, do you bind your RBO while the FBO is bound ? Try GL_DEPTH_COMPONENT instead of GL_DEPTH_COMPONENT24. Some cards prefer it.

Thanks for your suggestions. I’ve finally moved past the depth problem. I now have a RBO, with GL_DEPTH_COMPONENT image data. I think the final problem was a combination of not binding the RBO before setting the image data and specifying the right value for the image data. My screenshot finally looks correct. :slight_smile: I’ve been trying to fix another error with multiple render targets, and I think this was part of my confusion.

Well, the problem has reappeared. I can’t understand what is happening because the code makes perfect sense to me. I even read the little tutorial that came out shortly after I thought I conquered this topic. They don’t do anything different than me. Just to prove it to myself, I typed up their code. Did I make a mistake? Does my card have bugs? I just don’t know. Strangely, this was working for a couple weeks, then my laptop was borrowed for some demos, and it isn’t working again. I’ll include all the code this time, posted here . Jide, or anyone, please let me know if this code works on your machines. :slight_smile: If not, what needs to be fixed? I’m seeing an FBO error and no amount of reading or sample code has shown me the problem. I’m using a Dell XPS laptop with an NVidia 6800. Thanks a lot!

What exactly is the error you have ?

I’ll try to check your code but I’m not under Windows, so hoping that will compile.


Just have compiled it. I see a blue background, a red quad and a yellow cube. No errors about FBO incompleteness.

You might need to check your drivers.

I see an FBO unsupported error, and the quad has no red/yellow texture, just a black quad on a blue background. I’ll look for some new drivers. MANY thanks for the help Jide.

In even dumber news, I’m a total noob and I just found that I my machine had a manual setting for antialising. This is what changed and why I couldn’t get the FBO to work. It is finally working again.