I'm trying to implement Weighted, Blended Order-Independent Transparency in my engine. I need to read/access default framebuffer's depth buffer in off-screen transparency pass. What is the best way to do that?

Is there a way to read default depth buffer directly instead of copying it in every frame? If no how can I copy it then? Because I don't know default depth format do I?

Why use the default framebuffer's depth buffer at all? There's nothing particularly special about it.

Create your own depth buffer, and attach it to whatever framebuffer you need. You can even disable the default framebuffer to save memory if you don't need it as well.

It could save me to create another framebuff for opaque objects, since I render opaque objects to default frame buffer I need to default depth buffer for second pass.

There are three passes (see page):

1. 3D opaque surfaces to a primary framebuffer
2. 3D transparency accumulation to an off-screen framebuffer
3. 2D compositing transparency over the primary framebuffer ( using alpha blending )

For transparency pass it says "Test against the depth buffer, but do not write to it or clear it.". So it seems I don't need to write depth buffer in transparency pass, I only need to read opaque's one to test depth which is default depth buffer.

Binding default depth buffer  ( after opaque pass ) to transparency framebuffer would be nice but I'm not sure if it is possible or not.

As alternative I created a depth buffer for off-screen framebuffer (transparency) which is GL_DEPTH_COMPONENT24, it seems glBlitFramebuffer offer copying a buffer to another frame buffer. But what if formats mismatch? 32-bit vs 24-bit

Another alternative is that creating a framebuffer for opaque surfaces too. Then since I have depth buffer ID, I can bind it to another framebuffer I guess, then set depth mask to false. But I need to create another color buffer / color attachment and depth buffer for this framebuffer. I don't know which one is faster copying default depth using glBlitFramebuffer or this method.

There isn't a mechanism to bind the default framebuffer attachments to another framebuffer object, but there shouldn't be any need to perform a copy in the system you describe (as long as you don't mind allocating 2 colour buffers).

Typically I'd allocate a color attachment for each of your passes 1 and 2, a single depth attachment shared between passes 1 and 2, and then have pass 3 render directly into the back buffer (with no depth buffer).

Unless you are targeting very high resolutions/bit-depths, the memory for the extra colour buffer shouldn't be an issue.

52 minutes ago, swiftcoder said:

Typically I'd allocate a color attachment for each of your passes 1 and 2, a single depth attachment shared between passes 1 and 2, and then have pass 3 render directly into the back buffer (with no depth buffer).

It seems this is most reasonable thing to do, thanks for your feedback.