OpenGL ES 2.x: Any way to reuse the depth buffer for screen off and on screen?

I am doing a two-pass rendering where for the first pass I pass the texture and for the second pass I render to the screen.

I am doing the same polygons in both passes, but I am using different shaders. Specifically, the second pass uses a shader that takes the texture generated by the first pass as a parameter.

Currently my first pass has a textured videobuffer to bind color and a renderbuffer to bind depth (stencil disabled), while the second pass renders a default framebuffer (0).

It occurred to me that since I am passing exactly the same polygons in pass-2, the depth buffer will be the same as my pass-1 depth buffer. If I could somehow run the pass-2 depth buffer initialized with the pass-1 depth buffer, I could then change my depth check function to GL_LEQUAL and avoid a lot of unnecessary work for the pass-2 shader. You can also disable depth recording for this pass.

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

  • create your own framebuffer that uses the screen depth buffer (but writes colors to the texture anyway)
  • bind my own render to the default default framebuffer attachments.

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

+3


source to share


1 answer


From reading the OpenGLยฎ ES Common Profile Specification Version 2.0.25 it seems that none of these are possible.

Section 4.4.2 says:

Images attached to a Framebuffer can be attached to and detached from application-generated framebuffers. In contrast, image attachments with a framebuffer in the windowing system cannot be modified using OpenGL ES .

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



Section 4.4.3 shows that the first option is not possible ...

The renderbuffer object cannot be created using name zero. If renderbuffer is zero, then any previous binding to the target is broken and the target binding is restored to its original state.

Initially, the reserved name zero is bound to RENDERBUFFER

. There is no renderbuffer object corresponding to zero, so the client tries to modify or request the renderbuffer for the target RENDERBUFFER

, while zero is bound to generate errors.

... although it's less explicit. It is unclear if there is another name that could be used to refer to the standard renderbuffers framebuffer, although itโ€™s hard to imagine which name would make more sense than 0 as it is used by default elsewhere.

0


source







All Articles