Page 1 of 1

ZBufferBits

Posted: Sat Mar 14, 2009 4:00 pm
by asparagusx
Hallo

Is it possible to change the ZBuffer depth using the parameter ZBufferBits when creating a new device? It does appear to be used in some of the device drivers, but does not appear to be used in the DirectX9 device. I am using 1.5. I want to increase the ZBuffer depth, to try and solve some issues with Z fighting.

Thanks

Anton

Posted: Sat Mar 14, 2009 8:23 pm
by bitplane
The Direct3D9 device tries to create a 32-bit depth buffer but some bits are reserved for the stencil buffer. If you have a stencil buffer, it first attempts 24-bits of depth with 8-bits of stencil, then 24 bits of depth with 4 a bit stencil, then 15 bits of depth with a 1-bit stencil. If this fails or the stencil buffer is disabled, then it tries a 32-bit z-buffer, then 24, then 16.

So the best integer z-buffer is picked automatically in D3D9, if you need a better resolution try adding the floating point types, D3DFMT_D24FS8 and D3DFMT_D32F_LOCKABLE into the if(StencilBuffer) / if(!StencilBuffer) blocks in CD3D9Driver::initDriver

edit: I've added this to svn trunk, floating point z-buffers are enabled in d3d by default (if available).

Re: ZBufferBits

Posted: Sun Mar 15, 2009 4:00 am
by vitek
asparagusx wrote:I am using 1.5. I want to increase the ZBuffer depth, to try and solve some issues with Z fighting.
Have you tried working around the problem by increasing the camera near value (camera->setNearValue()) or decreasing the camera far value (camera->setFarValue())? Are the fighting surfaces at the same depth? If so, is there some way that you can offset one of them?

Travis

Posted: Sun Mar 15, 2009 8:47 am
by asparagusx
I have tried all sorts!!!! This is driving me nuts. I have changed near values, far values, even changed the driver to use the ZBIAS, but all to no avail. The problem is made worse by the fact that typically one of the co-incident planes will be transparent - which does not fit well with zbuffering. At the moment, I dynamically 'offset' the transparent mesh, by a distance towards/away from the camera viewing vector, which does actually solve the problem, but it does make the 'moved' mesh appear to be in the wrong place elsewhere within the drawing.

Anton

Posted: Sun Mar 15, 2009 9:35 am
by asparagusx
@Bitplane

I tried the SVN fix (ported back into 1.5) and I get an exception as soon as :

Code: Select all

		present.AutoDepthStencilFormat = D3DFMT_D32F_LOCKABLE;
		if(FAILED(pID3D->CheckDeviceFormat(adapter, devtype,
			present.BackBufferFormat, D3DUSAGE_DEPTHSTENCIL,
			D3DRTYPE_SURFACE, present.AutoDepthStencilFormat)))
is used (not using a stencil buffer). The DirectX surface cannot be created - i think this buffer format is not implemented on any cards.

BTW - very interesting article about the ZBuffer - I changed my near value from a default of 5 to 500 - fantastic results : http://www.sjbaker.org/steve/omniv/love ... uffer.html

Anton

Posted: Sun Mar 15, 2009 8:22 pm
by bitplane
Ah, I'll remove that if it causes crashes. After looking into it some more it seems its useless other than for shadow mapping anyway