[2.1] Reading depth buffer contents

[zxz]

Hello,

I have a use case where I want to read back the contents of a depth buffer to the CPU, as part of a one-shot non-performance critical feature. I cobbled together a quick proof-of-concept implementation with a compositor workspace, where I use the depth pool ID to get a handle of the depth buffer. In the end I get a pointer to the depth texture from the workspace instance.

However, functions such as GL3PlusDepthPixelBuffer::lockImpl and GL3PlusDepthPixelBuffer::blitToMemory are not implemented. Is there an underlying reason why those are unimplemented? Is this the correct approach, or is there perhaps an alternative way I can reach the depth data?

Thanks!

[dark_sylinc]

I can't remember if this is possible in 2.1 (it definitely is in 2.2) it is probable it is not; but a simple workaround is to copy the depth buffer to a regular texture and then map that texture.

When mapping the texture in 2.1; I strongly suggest that you cycle through 3 different textures in a triple buffer fashion e.g.

Code: Select all

i = frame_number;
render depth_buffer to rtt_texture[i%3]
map rtt_texture[(i+2)%3]
unmap rtt_texture[(i+2)%3]

This performs buffering/streaming and adds some frames of latency, but if you try to map the same rtt_texture right after issuing rendering commands to it, you're forcing the CPU to wait for the GPU to finish all of its work and that will be slow.

Ogre 2.2 introduced AsyncTextureTickets so that you can perform asynchronous transfers without having to double or triple the number of textures/workspaces.

Update: No, locking a depth buffer is not possible, use the render to rtt_texture trick.

However, functions such as GL3PlusDepthPixelBuffer::lockImpl and GL3PlusDepthPixelBuffer::blitToMemory are not implemented. Is there an underlying reason why those are unimplemented? Is this the correct approach, or is there perhaps an alternative way I can reach the depth data?

Having direct access to a depth buffer is not possible. We have to copy it to a staging area where it can be decompressed.
Unfortunately pre-2.2 Ogre code implemented texture blitting and locking by having direct access to the textures, which is slow and a PITA to handle.
Copying it by hand to rtt_texture via render and then locking rtt_texture is not the most efficient way, but it is certainly very similar to what should actually happen (in 2.2 we perform a copy to a staging texture and then give you access to that staging area).

[zxz]

Hi,

Yeah, my fallback solution was going to be copying it to a regular texture first, but I just thought I'd ask if there's another way. I'm just looking for a single-shot snapshot, not at all performance critical. So I will use a copy followed by slow readback. Thanks.

Cheers!