🔒 Locked

z buffer reading.

Started by Mark Duffill Jun 17, 2002 at 3:33 AM 7 replies 1.8k views

Original Post

Jun 17, 2002 at 3:33 AM

Is there any way in directx to read back the data in the z-buffer for any format? I know about using the D3DFMT_D16_LOCKABLE, which will allow you to lock the zbuffer surface and get the data. But if you need to run you z buffer in D3DFMT_D32 format ( to match the display surface etc) how the heck do you get it? I tried it in OpenGL and it works fine using glReadPixels(), but Directx won''t let you! (the lock fails). If you can''t this is a big bag of pants

Thanks.

CamelFly

Jun 17, 2002 at 3:48 AM

Could you show me how you lock your Z-Buffer, and how you create it?

I have searched for a way for some time as well..

Mark Duffill

Author

Mark Duffill

Jun 17, 2002 at 4:30 AM

using directx 8 I do the following:

  
LPDIRECT3DSURFACE8 ZBuffer;

// get surface

if( SUCCEEDED(Direct3DDevice->GetDepthStencilSurface( ZBuffer )) )
{
	D3DLOCKED_RECT rt;
	// this will fail unless zbuffer was created using D3DFMT_D16_LOCKABLE, which is pants

	// if you are running in 32 bit!

	if( SUCCEEDED(ZBuffer->LockRect( &rt, 0, D3DLOCK_READONLY )) )
	{
		// do stuff

		ZBuffer->UnlockRect();
	}

	// free

	ZBuffer->Release();
}

Note using CopyRects() also fails. ( ie try to copy it to a surface format you can lock!)

S1CA

169

S1CA

Jun 17, 2002 at 7:28 AM

1. Some chips (notably PowerVRs) don''t have any Z buffer. Their drivers will emulate direct Z access, but as you''d guess it''d be hideously slow.

2. Different chips use different formats for Z, some even have "compressed Z" etc - so say you''ve locked your 16bit buffer - what do those pixels mean ?... they could be fixed point?, they could be floating point?, integer?, big endian/little endian?...
A big problem is most manufacturers have never commited to revealing their specific Z format so you''ve essentially got yourself 16bits of chip specific data - what it means is chip specific...
The driver/D3D could convert the data to some common format, but AFAIK most won''t (it''d be bad for performance too - akin to swizzling).

3. AFAIK, #2 is a big reason why most chip manufacturers (not MS) won''t expose lockable Z in D3D. (D3D just exposes whatever formats the [D3D part of the] *driver* says it can do)

4. Some chips do support Z texture to normal texture copies - nVidia chips do - check out the shadow Z buffer stuff on their public developer site.

5. If this is for determining point occlusion for things like lens flares, its a damn expensive way of doing it unless you''re locking a good few frames after the render. Much faster (and more flexible) to do ray intersections.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Mark Duffill

Author

Mark Duffill

Jun 17, 2002 at 8:22 AM

Yeah Thanks that''s what I suspected.

Its not for lens flare or such. I was playing around with researching different occlusion techniques, ( search google for lazy view occlusion for examples ).

I feared it would be to slow, and so it is. ( Although I found I can render white polys to a texture and use that instead ).

Oh hum, just want to get away from human edited view culling systems ( ie portals ) since it is time consuming and error prone, and not to good for open areas.

Back to my old friend the drawing board!

Thanks.

Kippesoep

Jun 17, 2002 at 8:40 AM

quote:
Original post by S1CA
2. Different chips use different formats for Z, some even have "compressed Z" etc - so say you've locked your 16bit buffer - what do those pixels mean ?... they could be fixed point?, they could be floating point?, integer?, big endian/little endian?...
A big problem is most manufacturers have never commited to revealing their specific Z format so you've essentially got yourself 16bits of chip specific data - what it means is chip specific...

According to MSDN:
"All depth-stencil formats except D3DFMT_D16_LOCKABLE indicate no particular bit ordering per pixel, are not application-lockable"
and
"D3DFMT_D16 indicates a 16-bit integer value and an application-lockable surface." (I assume they mean "D3DFMT_D16_LOCKABLE" in this section)

Which makes sense. It is the only readable format and should therefore be uniform and non-specific. When you lock the surface, the data you read won't be compressed (it might be on the hardware, but the driver should handle that transparently).

That doesn't make your other points any less valid, though.

[edited by - Kippesoep on June 17, 2002 9:42:39 AM]

S1CA

169

S1CA

Jun 17, 2002 at 12:37 PM

Mark Duffill:

ah right. Such is the world of PC 3D coding - unless you can have a restrictive minimum machine spec you can''t assume you can do anything.

dPVS/Umbra does HOMs (amongst other stuff) with a software renderer for occlusion, the manual on their site contains lots of interesting info...

The 3D hardware guys are definately not in favour of anything which potentially destroys GPU->CPU parallelism, any kind of synchronous reads (such as locking a Z buffer) from 3D hardware is going to totally serialise things (i.e. totally trash any benefits of 3D hardware acceleration).

Kippesoep:

I''ll admit to not having read the docs regarding locking of Z buffers for a few years (the DX7 days) when it wasn''t specified so explicitly, and locking Z just gave you device specific data.
However, the way that quote reads to me still doesn''t tell you what the integer actually represents! The most sensible would be Z in the 0.0-1.0 Z buffer range scaled up to 0-65535.

I can see why many IHVs have chosen not to expose lockable depth formats though (past the other issues such as supersampling etc)

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Kippesoep

Jun 18, 2002 at 1:50 AM

quote:
Original post by S1CA
The most sensible would be Z in the 0.0-1.0 Z buffer range scaled up to 0-65535.

That''s what it does. Not exactly ideal, though.

Mark Duffill

Author

Mark Duffill

Jun 18, 2002 at 3:38 AM

Thanks S1CA,

I''ve dropped the HOMs idea since to prevent GPU stalls I would have to render the occluder polys, (low res model) in software to a low res buffer representing the screen.

However the time taken to do this would most likely be comparable to just drawing the damn thing using modern hardware ( GeForce+, I remeber the days when the first 3D cards struggled to draw any polys! ).

Case of an optimsiation making things slower!

*sigh*
So back to occluder volumns, which are nice but problematic to place and get fusion. ( this is for proper 3d occluders ).

Thanks again.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.