iPhone 5S - Possible Depth Buffer issue

Question

In my application, I render plane over plane. Lower plane has Z = 0, second one has Z = 0.5. If I render them (lower first), I got missing part of render, as shown on picture

On iPhone 4 and desktop (using ES emulator), there is everything correct and no problem. What could cause this bevaiour ?

Same problem occurs also for other parts of scene, like tracks, tubes (green and blue on this picture). Problem occurs, when I move camera

Answer 1

Ok... I have solved this. There was problem in my shader that caused depth buffer to be filled incorectly. I have used

precision mediump float;

and that caused geometry to be not precise and Z = 0 vs Z = 0.5 has been mixed together.

Changing precision to highp solved the issue.

Bottom line. This "optimalization" was huge mistake and never use mediump in Vertex Shader (unless you are facing some performance impact and even that its not worth it. The difference in rendering is not noticable)

Answer 2

(This is in response to your own answer, which is only partially correct)

You've got a case of Z-fighting going on, due to the mapping of your scene's Z values, to the z-buffer. This may be a non-linear mapping (1/f(Z) is common), but I'm not sure on floating point z-buffers.

Your scene is really simple, and while chunking more z-buffer range at the problem is a partial solution, it's at the cost of performance, and not really understanding the issue. You may well run into this same problem again even with the highest possible precision z-buffer you can use on your platform!

Look at your scenes; you want to map the z-range in the 3D scene, to the maximum possible range of values the z-buffer can store, else you're wasting chunks of the range of numbers the z-buffer can store. Calculating this mapping per-frame can be useful, depending on what you want to do with the z-buffer later on.

Have a look here for some calculations. Note, that with a floating point z-buffer, you may well be worse off than with an integer one if you're chucking away a lot of small numbers - that's where the vast majority of possible storable values of a floating point number are!