Is it possible to fill both depth buffer and color buffer within a MRT context using OpenGL and GLSL?

0
votes

Here's my situation:

I've written a small deferred 3D engine using MRT (Multi Render Target) to fill my G-Buffer (all my position, normal, color and specular textures are filled at the same time).

In addition I've attached to my G-Buffer FBO a Render Buffer Object (RBO) initialized as GL_DEPTH_STENCIL_ATTACHMENT (GL_DEPTH24_STENCIL8). So during the G-Buffer execution my 4 textures are filled simultaneously and the render buffer fills at the same time the stencil and the depth buffer.

I have 2 questions:

  • Is it possible to use for any reasons THIS depth buffer as a sampler2D uniform variable within a fragment shader for example I could use to compute something during the lighting pass (for instance, recover vertex position in view-space from depth)? It would be a gain of time to use this depth buffer directly!

If it's not possible :

  • Is it possible to fill a depth texture (GL_DEPTH_COMPONENT format) within a MRT? For example, is it possible to fill a depth texture and a color texture using MRT rendering technique ? (I tried without any success but maybe I got caught badly). Do I need to fill my color buffer using MRT, and the depth buffer separatly (two render passes are needed here instead of one)?

If it's not possible again what do you advice me ?

Thanks a lot in advance for your help!

1
openglglslshader
What problem did you get exactly? Did manage to create a texture with a depth(+stencil) internal format and attach it to the depth(+stencil) attachment points of your FBO? Then did you manage to use that texture normally in a shader (bind into a TU and sample using a sampler2D using the ordinary texture(depthSampler, coordinates); call)? – peppe

1 Answers

0
votes

Is it possible to use for any reasons THIS depth buffer as a sampler2D uniform variable within a fragment shader for example I could use to compute something during the lighting pass (for instance, recover vertex position in view-space from depth)? It would be a gain of time to use this depth buffer directly!

Yes, depth buffers can be samplers in a fragment shader and are accessed with the typical texture(depthTexture,...) command.

In a typical deferred rendering path you first write the gBuffer (the depth buffer is part of the gBuffer) and then you bind all gBuffer textures to samplers and use them while lighting calculations.

If you mean with 'THIS' depth buffer that you want to sample the currently used depth buffer you're writing into, then that is not possible. A texture can not be written and read at the same time (OpenGL ES might be an exception here).

Is it possible to fill a depth texture (GL_DEPTH_COMPONENT format) within a MRT? For example, is it possible to fill a depth texture and a color texture using MRT rendering technique ? (I tried without any success but maybe I got caught badly). Do I need to fill my color buffer using MRT, and the depth buffer separatly (two render passes are needed here instead of one)?

Yes as i said above, that is the typical way. Just attach the depth texture to the depth part of the framebuffer (or if it's a depth+stencil texture attach it to the depth+stencil part of the framebuffer). See https://www.opengl.org/sdk/docs/man4/docbook4/xhtml/glFramebufferTexture.xml

Update

I'm sorry, I somehow didn't read, that you're talking about RBOs.

No, the depth buffer of a RBO, can not be bound to a texture sampler (since it's not a texture). There are 2 ways to solve this problem:

  • Use a FBO instead of a RBO with a depth texture attached to it. (recommended)

  • Copy the data of the RBO to a depth texture. If you really want to do that, there are again 2 possible ways:

    • Create a FBO with only a depth texture attached to it and copy the RBO to that texture with glBlitFramebuffers see: https://www.opengl.org/sdk/docs/man3/xhtml/glBlitFramebuffer.xml
    • Copy the depth buffer to the CPU with glReadPixel and then copy it back to your depth texture. (The FBO approach is of course recommended, since it would be a GPU->GPU transfer.)