The next image is taken from the depth render buffer directly. (Depth testing works, i triple checked with various functions, …)
The black to white pixels represent the quads, which in turn consist of 2 GL_TRIANGLEs. The grayscale color represents the depth value (depth testing is enabled), thus the black quad is in front of all the gray quads. img254.imageshack.us/img254/3599/bugxcf.png
If we look more closely at it, we see a hole between the main chunk of the black quad’s pixels and one single black quad’s pixel at its border. As a side note, I am unsure if the black pixels belong to 2 different triangles of the same quad, or if the edge between the 2 triangles lies somewhere else.
My best guess is that the problem is how the triangle rasterization is applied. Assuming TOP_LEFT triangle rasterization, the gray quad’s pixel (gray quad is intersecting the black quad) take precedence over the black quad’s pixels that should have been there instead. This is unexpected, as the black quad is in front of the gray quads. Rasterization Rules (Direct3D 9) - Win32 apps | Microsoft Learn TOP_LEFT Rasterization rules
Any help would be much appreciated. I could be on the wrong track completely though. Im using OpenGL ES 2.0 and im on Windows 7.
[QUOTE=mucaho;1248727]
If we look more closely at it, we see a hole between the main chunk of the black quad’s pixels and one single black quad’s pixel at its border. As a side note, I am unsure if the black pixels belong to 2 different triangles of the same quad, or if the edge between the 2 triangles lies somewhere else.[/QUOTE]
Couple thoughts.
To your “I am unsure if the black pixels belong to 2 different triangles” comment, could the “black dot” be the 2nd triangle? Turn off everything but one of the 2 black triangles and see.
If not, turn off all the triangles except the big front (black) triangle. Do you still see the problem?
If so, could be a single-sample rasterization issue. That is, once the width of a triangle gets down to < 1 pixel, then the start/end of adjacent scanlines might not produce contiguous pixels. IIRC it’s all based on which pixel centers lie within the scanline start/end produced by the triangle edge equations.
If not, then how sure are you that you have depth buffering enabled and that this is a depth testing issue and not a draw order issue. If depth testing and writing are not enabled properly, then I’d expect to see what you show in your image if the medium gray quad that “seems” to be occluding near the tip of the black triangle is being drawn after the black triangle.
Thank you very much for your suggestions, Dark Helmet With your help I was able to figure out the source of the problem.
The black pixels belong to two seperate triangles, as you feared. De facto, the bottom triangle is producing the isolated black dot.
Is there a way to fix this? I can not afford to have those holes.
More precisely, I can not afford to have complete vertical holes / columns missing from the quads (like it’s the case now).
However, I can afford to have less precision in the vertical direction, thus if a row is missing from the quad it’s fine, as long as there is at least 1 pixel in every column the quad stretches to.
You mentioned something about a scanline rasterization method. Would flipping the x/y coordinate (rotating the screen for 90 degrees) fix the issue?
Im including some screenshots, maybe they are of some relevance:
Your wireframe results seem like what you want, with FILL just filling the holes between the edges. Try rendering with glPolygonMode GL_LINE and then with GL_FILL.
Yeah seems like the only way to fix it properly. A side note for people trying to use the glPolygonMode on OpenGL ES: glPolygonMode is not available. You have to manually draw GL_LINES.
I have tried snapping the vertices to multiplicatives of window coordinates (like to every 10th pixel in the vertical direction), but that introduces more problems than it solves.
With your help I was able to figure out the source of the problem.
