Jump to content
  • Advertisement
jakovo

DX11 Weird depth buffer values

Recommended Posts

Hi everyone!

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

WeirdDepthBuffer.png.49063416c42ce563060b3d6176131344.png

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? 

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

WeirdDepthBufferWithWireframe.png.19da73e33cf07673ac552c9062e4451a.png

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!