the precision issue in 16 bit Z-Buffer

Hi ,all:
I am working at a project that aims to develop a virtual globe system by using WebGL.
We have made the system work, but there is z-fighting problems.
I have heard from others that there exists a solution that use a perspective projection matrix,a matrix different from the projection matrix used in the OpenGL,which can resolve/relieve the precision problem.
Does anyone known the equation of the projection matrix? Thank you very much!

An easier option might be to use a higher precision depth buffer. All reasonably civilized hardware will support a minimum of 24-bit, so - have you tried 24-bit and, if so, does the problem go away?

hi,mhagain,
chrome does provide 24 bit z-buffer,but some other browsers only support 16 bit z buffer.mhagain,thanks for your reply!

There is one way to work around this, and that is to use glPolygonOffset. See also http://stackoverflow.com/questions/7...s-in-opengl-es.

Maybe this is applicable to your problem?

If you need an ultra depth buffer you can slice things into sections from front to back and draw them then from back to front.

Anything that is in both sides will be drawn twice but clipping should marry the results with any luck. If your globe is not very detailed like an actual planet, then this is probably the wrong way to go. But then 16bit can be killer. Any implementation of WebGL would probably conservatively use the highest precision depth buffer available. On a desktop that will be 24bits for consumer adapters.

Quote:

---

Originally Posted by kamimail

hi,mhagain,
chrome does provide 24 bit z-buffer,but some other browsers only support 16 bit z buffer.mhagain,thanks for your reply!

---

This doesn't make much sense. I'll admit that I'm not familiar with particulars of WebGL so I could be horribly wrong, but availability of depth buffer formats should depend on your hardware and driver, not your browser.

Quote:

---

Originally Posted by mhagain

This doesn't make much sense. I'll admit that I'm not familiar with particulars of WebGL so I could be horribly wrong, but availability of depth buffer formats should depend on your hardware and driver, not your browser.

---

mhagain is dead on correct. You can open up WebKit and observe that WebGL implementation is more or less (with some variation depending on the backend) just a wrapper (the class is GraphicsContext3D) over GLES2 with some extra junk about making a context current (or something else) when getting ready to draw to it and some extra jazz to get the image data from it to the rest of WebKit so it can draw the 3D canvas.

Additionally, there is mainstream portable hardware that only has a 16-bit depth buffer: NVIDIA's Tegra2, though they have something funky to help work around the z-fighting issues: http://www.khronos.org/registry/gles..._nonlinear.txt , but AFAIK, unless you have a special build of WebKit (or whatever browser you are using) you are not going to be able to coax the WebGL implementation to take advantage of it.

use ortho projection instead. With perspective projection all the precision is at the front. The further away from the camera you go the less precision.

Quote:

---

Originally Posted by dukey

use ortho projection instead. With perspective projection all the precision is at the front. The further away from the camera you go the less precision.

---

Ortho projection isn't much good if you're drawing a scene that you want viewed with perspective though, is it?

Just a thought. To get the most out of the depth buffer the clip space should be restricted to just the bits of the scene that are actually on display.

So if you need to show a globe. The near clipping plane should be right in front of the globe, and the far clipping plane should be right beyond the horizon.