PDA

View Full Version : z-buffer problems



Freebe
04-19-2004, 10:24 PM
Hello

I'm implementing a simple 2-pass renderer. The first pass renders the diffuse colors (textures), and the second pass renders the specular highlights.
What i'm doing is like this:

glDisable(GL_BLEND);
glDepthFunc(GL_LESS);
renderDiffuse(mesh);

glEnable(GL_BLEND);
glDepthFunc(GL_LEQUAL);
renderSpecular(mesh);

This works, and looks kind of nice, but on some polys there is artifacts. It looks like a z-buffer problem (the specular poly begcomes "jagged", if you know what I mean).
I have tried to adjust the clipping planes to increase the precision of the z-buffer but it doesn't make much of a difference.
I probably should mention that the rendering is done to a pbuffer (with 24bit zbuffer).

Anyone got a clue?

thanx fo your time.
- Freebe

plasmonster
04-19-2004, 10:52 PM
I assume you are refering to "z-fighting", or "stitching".
If you are rendering the same geometry twice, with exactly the same transformations, the zbuffer is unlikely the issue, unless you are using a mix of vertex programs and fixed function without position invariance.

flo
04-19-2004, 11:24 PM
Originally posted by Portal:

If you are rendering the same geometry twice, with exactly the same transformations, the zbuffer is unlikely the issue, unless you are using a mix of vertex programs and fixed function without position invariance.Well, some time ago, I noticed such depth artifacts on a GeForce2 using fixed function only. I rendered the same geometry twice, but once with enabled lights, once with disabled lights.

plasmonster
04-19-2004, 11:42 PM
flo, that would be a driver problem. There's a conformance spec a gl implementation must meet; position invariance is one guarantee in the spec. If you can't count on identical depth values being generated from identical inputs, all hope is lost! I'd be willing to wager the problem lies elsewhere.

Tom Nuydens
04-20-2004, 12:11 AM
The spec doesn't require invariance when enabling and disabling blending. Try rendering the first pass with blending ON and using glBlendFunc(GL_ONE, GL_ZERO), and see if that solves your problem.

Read appendix A of the OpenGL specification for the full list of states for which invariance is required. Changing any bit of state that is not on this list may cause the problem you're seeing.

-- Tom

Freebe
04-20-2004, 12:41 AM
Originally posted by Tom Nuydens:
The spec doesn't require invariance when enabling and disabling blending. Try rendering the first pass with blending ON and using glBlendFunc(GL_ONE, GL_ZERO), and see if that solves your problem.

-- TomThat makes sense. I'll try that as soon as I'll get home. Thanx!
- Freebe

plasmonster
04-20-2004, 12:05 PM
Tom makes a good point about the blending enable/disable. In fact, the spec doesn't guarantee invariance among blend parameters, though it is "strongly suggested".

Jan
04-20-2004, 01:49 PM
Originally posted by Portal:
flo, that would be a driver problem. There's a conformance spec a gl implementation must meet; Well, nVidia does NOT stick to everything. (Though they do with the position invariance).

Render geometry, push the projection matrix onto a stack, transform the projection matrx (however you like), pop the matrix, render the same geometry again - watch the fight: z against z...

Jan.

Jan
04-20-2004, 01:51 PM
Do i need to add, that this doesn´t happen on Radeons...

Freebe
04-20-2004, 11:26 PM
I rendered the two passes with blending enabled, but the z-fighting was still present.

It seemed to be worse on large polygons, so I tried to tesselate my large triangles, and now the z-fighting isn't there any more.

I maby should mention that I use the leaked nvidia 60 drivers, so that might be an issue.

(From what i can make of the specs, invariance is not needed for blending parameters, so this shouldn't be a driver issue.....just some lazy driver developers, or a difficult hardware implementation)
- F