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:
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).
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.
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.
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.
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.
Originally posted by Tom Nuydens:
[b]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.
– Tom[/b]
That makes sense. I’ll try that as soon as I’ll get home. Thanx!
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”.
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…
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)