4

I'm doing 2-pass rendering, where for the first pass I'm rendering to a texture and for the second pass I'm rendering to the screen.

I'm rendering the same polygons in both passes, but I'm using different shaders. In particular, the second pass uses a shader that takes the texture generated by the first pass as a parameter.

Currently my first pass has a framebuffer with a texture for the color attachment and a renderbuffer for the depth attachment (stenciling is disabled), while the second pass renders to the default framebuffer (0).

It occurred to me that since I'm rendering exactly the same polygons in pass-2, the depth buffer will end up looking identical to my pass-1 depth buffer. If I could somehow have the pass-2 depth buffer start out initialized to pass-1's depth buffer, I could then change my depth test function to GL_LEQUAL and avoid a lot of unnecessary work for pass-2's fragment shader. Depth writes could also be disabled for this pass.

So... is there some way to do one of the following?

  • create my own framebuffer that uses the screen's depth buffer (but still writes colors to a texture)
  • attach my own renderbuffer to the default framebuffer's depth attachment

The only workaround I can think of (and I haven't tried this yet, so I have no idea what kind of effect this will have on performance) is to have the second pass also render to a texture, and then have a third pass that just "blits" the texture to the screen.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Laurence Gonsalves
  • 137,896
  • 35
  • 246
  • 299

1 Answers1

1

From reading the OpenGL® ES Common Profile Specification Version 2.0.25 it appears that neither of these are possible.

Section 4.4.2 says:

Framebuffer-attachable images may be attached to, and detached from, application-created framebuffer objects. In contrast, the image attachments of the window-system-provided framebuffer may not be changed by OpenGL ES.

(emphasis mine) So the second option in the question is not possible.

Section 4.4.3 suggests that the first option isn't possible either...

A renderbuffer object cannot be created with the name zero. If renderbuffer is zero, then any previous binding to target is broken and the target binding is restored to the initial state.

In the initial state, the reserved name zero is bound to RENDERBUFFER. There is no renderbuffer object corresponding to the name zero, so client attempts to modify or query renderbuffer state for the target RENDERBUFFER while zero is bound will generate errors.

...though this is less explicit. It isn't clear if there's some other name that could be used to refer to the default framebuffer's renderbuffers, though it's hard to imagine what name would make more sense than 0 since it's used for the default elsewhere.

Laurence Gonsalves
  • 137,896
  • 35
  • 246
  • 299
  • It may not be in the spec, but I've reused a depth buffer with an offscreen rendered FBO and something drawn to the screen on iOS. Apple's implementation supports this, but they had one slight glitch in that the Y axis is flipped between their offscreen depth buffers and the onscreen one. They were going to fix this, but I haven't tried this again on a newer iOS version. – Brad Larson Apr 05 '12 at 17:58
  • @BradLarson Intesesting. How do you tell the offscreen FBO to use the onscreen depth buffer? Bind 0 to the depth attachment? – Laurence Gonsalves Apr 05 '12 at 20:27
  • 2
    At least on iOS, you still have to manually create a depth buffer for onscreen content and then attach it to the framebuffer you associated with the CAEAGLLayer which hosts the OpenGL ES content. Instead of creating a new depth buffer and attaching it to the display framebuffer, you can reattach your previously used one to the display framebuffer. Again, this works on iOS, but may not be the same for other platforms. – Brad Larson Apr 05 '12 at 21:16