Hi everyone!

Does anyone have a clue of what could be causing the depth buffer to look like this?

I'm trying to render a single mesh of a terrain (it's easy to distinguish from the depth buffer), but it looks as if it was rendering the terrain with a weird texture on it... instead of the actual depth of the terrain.

I am clearing the depth/stencil view before that so I really have no clue of why could this happen.

Any ideas? 

What are you using to actually view the depth buffer? Usually the best way to sanity check is to use the Visual Studio graphics debugger, take a snapshot, and compare what it has to what you have.

40 minutes ago, Promit said:

What are you using to actually view the depth buffer? Usually the best way to sanity check is to use the Visual Studio graphics debugger, take a snapshot, and compare what it has to what you have.

This image is a snapshot taken from NVIDIA Nsight.

Here's another one of the DepthBuffer with the mesh wireframe overlapped for comparison.. 

There seems to be a pattern with some vertices, at first I thought it might had to do with a wrong winding order of some triangles, but I have set D3D11_CULL_NONE, so if that was the case it should be drawing them regardless.

I find it hard to believe the depth buffer actually has values in it that represent this pattern. More likely it's some a failed visualisation of the data. Perhaps something to do with interpreting floats as uints or via versa, or maybe a quirk related to how Nsight is dealing with a 24-bit depth buffer?

Have you tried another Graphics Debugger such as RenderDoc or Intel GPA?

18 hours ago, ajmiles said:

Have you tried another Graphics Debugger such as RenderDoc or Intel GPA?

thanks ajmiles,

Yes, the depth buffer is consistent across NVidia NSight, Intel GPA and RenderDoc... and needless to say, the application renders the terrain generating holes randomly everywhere while moving the camera (i.e. they're not fixed for a different point of view).

Just now, jakovo said:

thanks ajmiles,

Yes, the depth buffer is consistent across NVidia NSight, Intel GPA and RenderDoc... and needless to say, the application renders the terrain generating holes randomly everywhere while moving the camera (i.e. they're not fixed for a different point of view).

Maybe you could share a RenderDoc capture?

What is your near/far Z values?

Thanks everyone for your answers,

So, I finally found the problem... it was that the terrain mesh (which is being proceduarlly generated) had the values for the vertices' position attribute (in local-space) around the millions, so looks like that was driving the GPU crazy... just forced it to stay in the thousands and everything worked as expected.

(Interesting though, on Intel HD 4600 graphics there was no rendering issue)

Oh well, i'm just leaving the answer here if anyone else runs in such a weird behavior.

1 hour ago, jakovo said:

Thanks everyone for your answers,

So, I finally found the problem... it was that the terrain mesh (which is being proceduarlly generated) had the values for the vertices' position attribute (in local-space) around the millions, so looks like that was driving the GPU crazy... just forced it to stay in the thousands and everything worked as expected.

(Interesting though, on Intel HD 4600 graphics there was no rendering issue)

 

Oh well, i'm just leaving the answer here if anyone else runs in such a weird behavior.

It still shouldn't be causing this problem. Please post your near/far values as requested by vinterberg. A too small near value will screw up your depth precision. Better to fix the problem at the source than patching it.