General Question: Z-Buffer Cannot Be Read Under DirectX 8.1?

[Pit_Viper]

Greetings All,

It appears that there are some truly knowledgable people in the forum, so I've decided to stop by here in order to pose a technical question.

I stopped by the UbiSoft forums in order to inquire about the lack of the depth-of-field effect in the PC version (demo) of Splinter Cell in night vision/sniper mode. I received the following reply (http://forums.ubi.com/messages/message_view-topic.asp?name=pcdemo&id=zzmcr):


It turned out that the depth of field effect is going to be pretty hard (and expensive) to include in Splinter Cell - PC. On xbox, you can read the Z-Buffer and use it to select different level of mipmapping levels (blur levels) per pixel to create that nice effect. On PC, you can't read back the Z buffer. The only way to do it would be to create a Depth texture, do a render there and then use this depth texture to do the same thing.


The effect is obviously possible - nVidia has an example on their developer relations web page (http://developer.nvidia.com/view.asp?IO=depth_field) (UbiSoft's Xbox implementation, in theory, seems to be a bit more straightforward, however).

My question: Is the inability to read the Z-buffer a DirectX 8.1 limitation?

Thanks in advance!

[Pit_Viper]

I just did a quick search under the MSDN Direct3D documentation. It appears that a pointer to the Z-buffer can be obtained with: IDirect3DDevice8::GetDepthStencilSurface(...). Now I'm not sure if I completely understand the reply that I was given...

[pcchen]

In D3D8, only one Z format is lockable (D3DFMT_D16_LOCKABLE), and not all cards support it. Other formats are not lockable and bit pattern/ordering/size are not guaranteed (e.g. D3DFMT_D24X8 can be integer Z buffer on card A and floating point Z buffer on card B).

[Simon F]

The performance would also suffer because a Z buffer read would completely stop the CPU and graphics chip running in parallel.

[embargiel]

Judging from you guys' reply, it seems that DX 8.1 that limited the ability to read back a Z-buffer? So Xbox uses a totally different DX architechture than those that be used in PC, as we know that NV25 is almost identical with NV2X.

[antlers]

I might be seriously out of my depth here...

I think it's not a DirectX limitation so much as an AGP one; with the XBox unified memory architecture you don't get the same penalty for reading from the Z-buffer, and you also know exactly what the Z-buffer format would be. I think 3dmark2003 does depth blur with DirectX 8 pixel shaders, which I guess gets around this problem and would be the way to do it on the PC.

[pcchen]

I don't think AGP is the problem, since the effect is not done by CPU.

NV2X has the ability to copy Z buffer into a depth texture. It is not an official DX8 function, although you can do it in their drivers.

[antlers]

If the effect is not done on the CPU, why is the ability to lock the z-buffer relevant?

[Simon F]

If the effect is not done on the CPU, why is the ability to lock the z-buffer relevant?

The lock is to stop concurrency issues, i.e. simultaneous access by GC (graphics chip) and CPU. At a particular instant, the GC is probably processing a poly that you sent to it perhaps tens, hundreds, or even 1000s of polygons ago. A lock forces the system to wait until all of this goes through and finishes processing.

It's best to avoid locking the Z buffer.

[antlers]

And again I ask, if the effect isn't done on the CPU, why is the ability to lock the Z-buffer relevant? Am I missing something?

I think UbiSoft is being a little fuzzy, and they just don't want to support the feature on the PC because it requires pixel shaders, and they don't think there is enough of a DX8+ installed base to justify it.

[pcchen]

Well, perhaps. Since you don't need to lock Z buffer to copy its content, however, it is not an official DX8 operation (perhaps not even an official DX9 operation). That is, it is very likely to be limited to NVIDIA's hardwares.

Another method is to render a depth texture. As in depth of field effect, you don't need a high precision depth texture. 8 bits precision may be sufficient. So a simple, linear textured rendering is enough for it.

[Simon F]

And again I ask, if the effect isn't done on the CPU, why is the ability to lock the Z-buffer relevant? Am I missing something?
But perhaps the effect requires the CPU to sample the Z buffer in order to compute the amount of blurring required in each area. The actual image processing (i.e. texuring with forced levels of MIP mapping) would, no doubt, be done in the GC.

[davefb]

1. wierd of them to say " we can't do this though we know how we could , by rendering to a depth texture"

2. is this a sneaky way to avoid a "what poly am i looking at" ray projection/intersection,, ?

-dave-

[darkblu]

1. wierd of them to say " we can't do this though we know how we could , by rendering to a depth texture"

2. is this a sneaky way to avoid a "what poly am i looking at" ray projection/intersection,, ?

-dave-

about 2 - yes. that's a very easy way to obtain a viewer-to-something collision vector in screen space. precision-wise, though, that costs due to z-buffer distribution with depth.

..with the risk of getting bad rep on this board, i can admit (not w/o relying on the judical clause of remoteness) that i've used this in a comercial engine, and at the time and on the hardware it was tested on the zbuffer locks did not incur such a dramatic performance hit as one would assume.

[DeanoC]

..with the risk of getting bad rep on this board, i can admit (not w/o relying on the judical clause of remoteness) that i've used this in a comercial engine, and at the time and on the hardware it was tested on the zbuffer locks did not incur such a dramatic performance hit as one would assume.
We locked the colour buffer for SH2PC which was released Winter 2002. The classic lens flare problem (as much as IHV complained it was the only good way), now days you would use your new fangled Dx9 async query.

You had to be careful and if possible avoid it but it didn't make any difference to our framerate. And that was with 250,000+ triangles per frame complex vertex and pixel shaders at high res (1600x1200).

Locking the z-buffer might be much worse mind...