Depth Check Oddities

Problems building or running the engine, queries about how to use features etc.
Post Reply
TheWanderer
Halfling
Posts: 44
Joined: Fri Apr 22, 2005 3:58 pm
x 4

Depth Check Oddities

Post by TheWanderer »

I'm having an issue where two quads drawn to the same location in a certain order are showing odd behavior. Specifically, the quad which is drawn first appears on top of the quad that is drawn second. Debugging the pixel on Pix shows that the pixel from the second quad which should have been drawn failed its depth test. The depth test is set to default (which should be less_equal), so I'm unsure why the test was failed.

I should add, each quad is being instantiated in a separate InstanceManager.

I looked at the vertices which form the two quads and their positions (post vertex shader) are the same.
Quad A:

Code: Select all

-0.107,	0.316,	0.003
0.044,	0.060,	0.003
0.044,	0.316,	0.003
-0.107,	0.316,	0.003
-0.107,	0.060,	0.003
0.044,	0.060,	0.003
Quad B:

Code: Select all

-0.107,     0.316,     0.003
0.044,      0.060,     0.003
0.044,      0.316,     0.003
-0.107,     0.316,     0.003
-0.107,     0.060,     0.003
0.044,      0.060,     0.003
Here is an example. The door is the image on Quad A which should be behind the cube outline, which is on Quad B.
Image

If I move the position of the second quad closer to the camera by two units, the image is drawn correctly.

Any thoughts on why this could be happening? Thoughts on what I could check to see why the test is failed?

Thanks for any help :)

Ogre Version: 1.10.11 (Xalafu)
Operating System: Windows 10
Render System: DirectX 9
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5299
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1280
Contact:

Re: Depth Check Oddities

Post by dark_sylinc »

Aside from a missing depth buffer as a possibility, PIX emulates the pipeline using CPU code, but displays the render using your GPU. That means the actual values may slightly differ from the ones executed by the GPU.

Floating point precision is very brittle, specially when you push it to such extremes. For example (a + b) - c does not necessarily produce the same output as a + (b - c).

A simple reorder in which floating point instructions are executed in PIX CPU vs in your GPU could explain this behavior.

You shouldn't rely your rendering order behavior on such extremes, as you are not guaranteed the GPUs will execute your code in the exact floating point order; so even if it looks as expected in a particular GPU, it won't on another or even in the same GPU after a driver update.

If you need to enforce a particular order, either space them apart, alter the vertex shader so there is a small bias, disable depth testing, or use stencil tests.

Cheers
Post Reply