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.
SlimDX WPF No Z-Buffer
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...
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()):
Rather use something like (switching near and far, and yeah, a near of 0 isn't good either)
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:
This is not the one you provided two posts ago . 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
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 . 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
yes, here was my first mistake:
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.
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.
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)
I wonder why. I don't do this, because...
If you do this:
... and then forget to fill all entries of result the compiler will scream with an error:
This is pretty useful information, so why mute it ? Shader debugging is hard enough.
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
Popular Topics
Advertisement