PDA

View Full Version : glCullFace and z-fighting?



billy
02-02-2004, 02:51 AM
Hello,

I use glCullFace to show the inside and outside of a set of polygons with diferent colors. The problem is even if the polygons form a solid completly closed like a sphere, I can still see the inside color at some edges like a z-fighting effect. How can I solve this problem?

Thanks in advance,

Bill.

[This message has been edited by billy (edited 02-02-2004).]

V-man
02-02-2004, 09:58 AM
Since you don't say what you are doing, I'm assuming you are rendering the sphere twice : 1 for back face, one for front face.

You can just use glMaterial(GL_FRONT, ...)
and glMaterial(GL_BACK, ....)
and render once without culling.
Look up glColorMaterial in case you don't use lighting.

jwatte
02-02-2004, 10:40 AM
It's quite possible the problem is Z fighting with the second pass. I don't think front/back sides are necessarily invariant.

Doesn't that require support for LIGHTING_TWO_SIDE? I didn't think that was widely supported on consumer hardware.

If you're running on CAD cards, I suppose it's all good.

rgpc
02-02-2004, 01:26 PM
glPolygonOffset() should help to remove the artifacts - and is available on consumer level cards.

evanGLizr
02-02-2004, 10:14 PM
Originally posted by jwatte:
It's quite possible the problem is Z fighting with the second pass. I don't think front/back sides are necessarily invariant.
You can bet it is! Otherwise it would go against corollary 17 of the invariance rules (besides being non-sensical):



17. (No pixel dropouts or duplicates.) Let two polygons share an identical edge
(that is, there exist vertices A and B of an edge of one polygon, and vertices
C and D of an edge of the other polygon, and the coordinates of vertex A
(resp. B) are identical to those of vertex C (resp. D), and the state of the the
coordinate transfomations is identical when A, B, C, and D are specified).
Then, when the fragments produced by rasterization of both polygons are
taken together, each fragment intersecting the interior of the shared edge is
produced exactly once.





Doesn't that require support for LIGHTING_TWO_SIDE? I didn't think that was widely supported on consumer hardware.


<ironic mode on>
I didn't know an OpenGL-conformant implementation was allowed to implement a subset of the 1.0 core http://www.opengl.org/discussion_boards/ubb/wink.gif
</ironic mode off>

harsman
02-03-2004, 02:49 AM
I think nvidia have supported two sided lighting since the GeForce 3 or so. Don't know about aTI, but since they reuse their cores for professional solutions I would guess it's supported by them too.

billy
02-03-2004, 03:27 AM
Originally posted by V-man:
Since you don't say what you are doing, I'm assuming you are rendering the sphere twice : 1 for back face, one for front face.

You can just use glMaterial(GL_FRONT, ...)
and glMaterial(GL_BACK, ....)
and render once without culling.
Look up glColorMaterial in case you don't use lighting.



Yes, that is what I am doing. But... will that extra render without culling slow down the performance?


[This message has been edited by billy (edited 02-03-2004).]

rgpc
02-03-2004, 06:06 PM
He's not saying render a third time. He is saying that you should stop what you are doing and just do a single pass with two-sided lighting enabled.

V-man
02-03-2004, 10:57 PM
>>>17. (No pixel dropouts or duplicates.) Let two polygons share an identical edge
<<<

The problem with this is that it doesn't specify if the triangles can be on top of each other while they share a single edge while this condition is met:

tri1_vert1 == tri2_vert1
tri1_vert2 == tri2_vert2
tri1_vert3 != tri2_vert3

I imagine if the trangles are side by side, then there is no problem.

I have seen an implementation (Nvidia, old detonator and maybe the problem persists) where one of the triangles was lit but the other one wasn't, so a few black(dark, unlit) pixels were visible near the shared edge.

When I enabled culling, the black (dark, unlit) pixels dissapeared since the triangle was culled.

The definition should also mention poly orientation.

Nicolas Lelong
02-04-2004, 01:52 AM
Hi,

I would _not_ recommand using double sided lighting if critical performance is needed on consumer cards...

Although it seems to work fine most of the time, for my latest tests on NVidia GeForceFX boards and ATI boards, double sided lighting slowed down things a lot (I don't have figures though...)

This is not even accounting that GeForce 1&2 boards do double sided lighting in software, and that using VAR with it reduces performance to a mere crawl !

just my 0.02

Nicolas-

AdrianD
02-04-2004, 03:56 AM
double sided lighting works fine on most hardware.
there are no problems at all with ATI and NVidia.(NVida had a problem - a big slowdown - with gf2 systems in the past, but this bug is fixed since the forceware is released...)