SlimDX WPF No Z-Buffer

Started by
16 comments, last by unbird 12 years, 6 months ago
Shader looks fine. Could you attach a minimal project (Edit: The WinForms variant, WPF doesn't seem to work with PIX here, please) ?

Also: Check against the reference device, I begin to suspect you have a driver issue.
Advertisement

Shader looks fine. Could you attach a minimal project (Edit: The WinForms variant, WPF doesn't seem to work with PIX here, please) ?

Also: Check against the reference device, I begin to suspect you have a driver issue.


WinForms sources:
http://www.rush.by/source.zip

System config:
i5-2500, Win7 x64, nVidia GTS450 with latest drivers and updates.

When I change in DepthStencilStateDescription

DepthComparison = Comparison.Less

to

DepthComparison = Comparison.LessEqual

I see that something changed, when peak(as on video) is in far side of scene Z-buffer is ok, but if peak is in near side - z-buffer fault. On video "DepthComparison = Comparison.Less".
I'm missing the Atomicus.Chart.Axis project to compile it (referenced in Atomicus.Chart.Interface).

EDIT: Sorry, my bad, had some other troubles (was still working with the older version of SlimDX). I can debug now...

I'm missing the Atomicus.Chart.Axis project to compile it (referenced in Atomicus.Chart.Interface).


i forgot to remove reference, sorry, it is not used, can be removed.
Ok, first your error was the perspective projection (in DXRenderer.GetWorldViewProj()):

Matrix.PerspectiveFovLH((float)Math.PI / 4f, 1f, 100f, 0f)

Rather use something like (switching near and far, and yeah, a near of 0 isn't good either)

Matrix.PerspectiveFovLH((float)Math.PI / 4f, 1f, 0.1f, 100f)

Then I had a hell of a detour. It really looked stubborn, just as if depth wasn't written ever. Played around with swapping calls and setting everything again prior to drawing. That did not help. Unfortunately I could not PIX it either, so my next steps were to compare and re-incorporate stuff from a test project I did two days ago (WPF sample with a working depth).

Comparing all descriptions/flags: Everything looked fine.

I changed the resized logic: You recreate almost everything - including the device (InitD3D is called twice at startup!). I suspected a forgotten/wrongly bound view or a backbuffer/depth size mismatch or something. So I used SwapChain.ResizeTarget/ResizeBuffers instead, grabbing the dimensions once only (with the needed texture and view recreation). Did not help either.

Suspecting your mesh, I used my grid mesh. Same behaviour.

Then I finally looked closer at your shader:

struct PS_OUT
{
float4 col: SV_Target;
float dep: SV_Depth;
};

//...

PS_OUT PS( PS_IN input )
{
PS_OUT output = (PS_OUT)0;
output.col = input.col;
output.col.g = 0;
return output;
}


This is not the one you provided two posts ago :P. The (PS_OUT)0 cast will overwrite all your real depth values with zero. That's the problem.

Omitting SV_Depth output in the pixelshader finally gave a correct result.

I think you owe me a favor :wink:
yes, here was my first mistake: Matrix.PerspectiveFovLH((float)Math.PI / 4f, 1f, 100f, 0f)

the result of this mistake was like Z-Buffer not work and i tried everything about Z-Buffer, but nothing about projection matrices.

And my last hope was to make depth calculations manually in shader(or something like this) and I started write something in shader :)

Now everything works fine, even in WPF. Thanks to unbird.

P.S. Really I see that DirectX/SlimDX rendering cannot depend on WPF, because rendering to shared texture is made just in .Net, not in WPF or WinForms. So I think chlerub can also solve his problem.
I have a different problem, since my code works just fine in WinForms but not in WPF. Also mind i'm using DirectX11.
I'll upload a sample project asap.
@Feuerrader: You're welcome. Glad to hear it's working in WPF, too.

I wanted to add something, though it's a bit off topic. I see this pretty often (Output being some struct)


Output result = (Output)0;
//...


I wonder why. I don't do this, because...

If you do this:

Output result;
// ...
// fill result with values
// ...
return result;


... and then forget to fill all entries of result the compiler will scream with an error:


error X4000: variable 'result' used without having been completely initialized


This is pretty useful information, so why mute it ? Shader debugging is hard enough.

This topic is closed to new replies.

Advertisement