   Keeping the Z buffer between render targets
  Hi, If i render to one render target, switch to another but dont clear the z-buffer, are the contents of the z-buffer still guarranteed to be in tact? I dont want to use MRT's because i want render targets with different bit depths but same resolution. I ask because i dont want to have to do a Z buffer fill pass for each render target.Thanks in advance,Ross   
  Yes, it's possible to use the same depth buffer with more than one render target as long as they're all compatible with said depth buffer.  It won't be cleared until you explicitly clear it.   ;  great, thanks   ;  In particular, make sure that the antialiasing settings match up -- this mainly comes into play when dealing with render targets you've created versus the render target attached to the device. Also remember that the driver can cause your app's main RT to get antialiased even when you haven't asked for it.   ;  Another thing to watch out for is setting DepthStencilDiscard in the PresentationParameters to true. When you do that, the DS surface is discarded on each SetRenderTarget (not each frame like I was expecting). I'm not sure if this happens on all drivers, but it does with mine, so I'd avoid it.Hope this helps.   ;  I have swap effect discard set, Is that ok or could that corrupt the z buffer? I'm not calling present multiple times, just BeginScene, EndScene on different render targets.I dont have depth stencil discard set.;  It doesnt seem to keep it either. If i clear just the target buffer an not the depth/stencil buffer it still seems to clear the depth buffer too because if i turn off z writes then objects are drawn on top of each other. Anyone any suggestions?Thanks;  ok, sorry about all the posts but i am a little confused. If I only clear the target and not the z buffer, then nothing is rendered. Its as if the depth buffer is being filled with 0s so that every depth tests fail. also my frame rate drops to 1/3 what it was. Anyone have any ideas?There is probably not much need for this but this is what im doing:  I loop for 4 render targets and call Beginscene on each render target before this code which should clear the buffers (K is the loop counter).if (K == 0) wigl->device->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER,  gBackColour, 1.0f, 0);elsewigl->device->Clear(0, NULL, D3DCLEAR_TARGET, gBackColour, 1.0f, 0);Also another weird effect is if i put in D3DCLEAR_STENCIL too then the whole thing fails even though i do have a stencil buffer (D248S).Any advice at all would be appreciated as im going crazy on this one. ThanksEDIT: also im using an directx managed depth stencil surface through the present parameters.. (dont know if that makes a difference)  Will it make a difference if the render targets are not the same pixel format? (they are the same bit depth at the moment though, 32 bits : A8R8G8B and G16R16)EDIT: fixed the code, had D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER on both clear calls[Edited by - jrmcv on September 11, 2007 2:40:32 PM];The metaphysics of zbuffers aren't my cup of tea, but I'll give it a shot.Quote:Original post by jrmcvok, sorry about all the posts but i am a little confused. If I only clear the target and not the z buffer, then nothing is rendered.Isn't this expected behavior, for color buffers other than the 1st one at least? You clear the targets so they're empty, but the backbuffer retains the scene from the 1st target so all pixels in subsequent color buffers fail the z-test.Quote:There is probably not much need for this but this is what im doing:  I loop for 4 render targets and call Beginscene on each render target before this code...Exactly how are you swapping your render targets? If you're using RenderToSurface, it might be trying to be helpful and messing with your depth/stencil surface.Quote:Also another weird effect is if i put in D3DCLEAR_STENCIL too then the whole thing fails even though i do have a stencil buffer (D248S).That's odd, but it's gonna be hard to say something useful on this without more information. How does it fail exactly, what does the output from the debug runtimes tell you? For this entire problem, the debug runtime output would probably be your best bet btw.Quote:EDIT: also im using an directx managed depth stencil surface through the present parameters.. (dont know if that makes a difference)The auto depth stencil flag? Going from the docs it shouldn't interfere with your clearing scheme, but I'd keep this one in mind as a possible cause of the error if you don't gain other insights from the debug output.Quote:Will it make a difference if the render targets are not the same pixel format? (they are the same bit depth at the moment though, 32 bits : A8R8G8B and G16R16)It might not make a difference, but I think it's safe to assume that this isn't exactly typical usage, so the behavior across various devices might not be very reliable. You could use the reference device to see what the expected behavior should be, but to be sure I'd stick with one format if possible.Hope this help :);i made a mistake in the code i showed before but think you know what i meant. just to clarify anyway with more details about the render target swapping://types: LPD3DXRENDERTOSURFACE RenderTarget[4]; IDirect3DSurface9 *RenderSurface[4];for (int K=0;K<4;K++){RenderTarget[K]->Beginscene(RenderSurface[K], 0);if (K == 0) wigl->device->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, gBackColour, 1.0f, 0);elsewigl->device->Clear(0, NULL, D3DCLEAR_TARGET,gBackColour, 1.0f, 0);RenderTarget[K]->EndScene(0);}// device->BeginScene / EndScene etc..Quote:Isn't this expected behavior, for color buffers other than the 1st one at least? You clear the targets so they're empty, but the backbuffer retains the scene from the 1st target so all pixels in subsequent color buffers fail the z-test.Im not sure what you mean here. I didnt think there would be back / front buffers on render targets to a texture. I thought this would be a single surface that you update directly whenever its required. Quote:That's odd, but it's gonna be hard to say something useful on this without more information. How does it fail exactly, what does the output from the debug runtimes tell you? For this entire problem, the debug runtime output would probably be your best bet btw.I cant find any errors on it other than it fails and if i switch to D32 (a format i used to use a lot on my older graphics card) then the create device fails. Its not really that important because i am not using the stencil buffer and thought it would be a much quicker clear if it didnt have to skip every 4 byte.Quote:    Quote:    Will it make a difference if the render targets are not the same pixel format? (they are the same bit depth at the moment though, 32 bits : A8R8G8B and G16R16)It might not make a difference, but I think it's safe to assume that this isn't exactly typical usage, so the behavior across various devices might not be very reliable. You could use the reference device to see what the expected behavior should be, but to be sure I'd stick with one format if possible.I am thinking of switching to MRTs to avoid all these problems and the possible future problems but am worried about performance on some graphics cards (i read that MRT can make things a lot slower in some cases). I also dont want to limit compatability. I hear Half-life 2 used MRT's but i have some friends with fairly low end machines that can run it no problem. Is this because they have a multi-pass method too?  Sorry this is a bit off topic.