Login  Register

Re: Seeking Help with OpenGL Depth Buffer Issue

Posted by xghost on Oct 05, 2014; 11:35am
URL: https://forum.jogamp.org/Seeking-Help-with-OpenGL-Depth-Buffer-Issue-tp4033219p4033272.html

jmaasing wrote
My next guess would be that your math is wrong somewhere.
The math appears to be ok, though I still keep an eye out for those just in case and I certainly welcome more specific feedback. (I may've been looking at this for long enough to be missing it... just like missing typos in a long essay and you've re-read many times.)

jmaasing wrote
If your original code would result in "all white" triangles that means your depth value is always >= 1.0 which is a problem.
I mentioned before that I had tried that already and that the depth values seemed to all be the same (yes, it produces white objects). I also mentioned the behavior difference between using GL_LESS and GL_EQUAL. From what I've read, my understanding is that the [0.0, 1.0] depth range is actually at normalized device coordinate (NDC) space, which is after the 1/w component divisions, etc. These transformations in the pipeline already take care of making sure that the depth values are within the [0.0f, 1.0f] range. (Feel free to correct me if I'm wrong.)

Based on the output of gl_FragCoord.z and the behavior with GL_EQUAL/LESS, they all seem to have the same depth value of 1.0f, which would explain why the objects get rendered with the EQUAL function, but not the LESS function while using a depth clear value of 1.0f (b/c no fragments have depth values LESS than 1.0f and fail depth testing and get discarded). I looked at the math in the vertex shader (project2/shader.vert) and the construction of the perspective view/projection matrices (MathUtil) again, but they seem ok. (The MathUtil code is from reference material.)

One part of particular interest/concern is in how the VBOs are being used, too. I expected the current translation/position to be the one responsible for affecting fragment depth values...and I can see the position vectors updating as expected by printing the values from the Java code before sending them to the shader via the uniform, but I don't think I've observed the expected effect on the fragment depth value and this is where I feel I've misunderstood something important.

Any ideas?