Yes.
as dorbie + i said polygonoffset is needed else youre gonna get zbuffer fighting
this brings me to my own question about caustics do caustics appear on the waters surface ie is the second shot correct or not (i have the feeling they dont) http://uk.geocities.com/sloppyturds/caustics1.jpg http://uk.geocities.com/sloppyturds/caustics2.jpg
No, they dont appear on the surface of the water. What you do get though, is refraction, which undulates with the waves.
I’m still not convinced that multipass requires glPolygonOffset. I’ve done a helluva lot of multipass on geforce cards, and I have never had any Z fighting.
The only time I ever did, was using vertex programs for 1 pass, and fixed function for the 2nd pass.
Nutty
I agree with Nutty, here. Come on, even old games have used multipass effects without glPolygonOffset - maybe someone should tell Carmack that he better use glPolygonOffset in id Software’s new DOOM game ( and fix all the Quake games ).
Using glPolygonOffset for multipass effects MAY be required for some weird states ( on some weird old hardware ) but ordinarily it won’t be required.
For multipass, I just use GL_EQUAL.
I only use glPolysonOffset when rendering 2 “different objects” that are really closed.
I always though that was how it was supposed to used.
[This message has been edited by Gorg (edited 01-13-2002).]
“Appendix H: OpenGL Invariance” in The Redbook has some good infomation on this - see the second last paragraph,
http://ask.ii.uib.no/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG
Hi
Ok…, i found an interesting thing.
I’m using a clipplane to clip the landscape that is above the water level., so i only have caustics below the water.
The interesting is that if i disable the clipplane i have a wonderful scene with no z-fighting…, Why ? Why a clipplane does this ?
Bruno
PH, that is the test, not the fragment values which are created. There is a deliberate opt out clause in the spec for this. You can look for evidence to the contrary but it won’t change the spec.
Just look at Bruno and his clip plane, that screwed up his depth fragments, possibly on triangles that weren’t even clipped, but perhaps they were. Other things can cause similar problems, and worst of all changing hardware platforms can have an effect you do not anticipate.
Bruno,
clipping the geometry introduces rounding errors which probably produces different z fragments on clipped geometry. The solution is still glPolygonOffset. As I said earlier, the suspected problem may not be the culprit, but I know what the solution is.
There is an alternative solution. When you clear the screen clear the stencil buffer to 0. Then when you draw the water surface write a stencil value of 1 on a depth pass, next draw the caustics but test against stencil == 0. The benefit is you can have non planar water and still only write to submerged fragments.
Hmm… thinking about this, if you draw the water before the caustics a simple depth test will prevent caustics above the water, so turn off clipping, and just draw terrain, then water then caustics and it will work when you are below the water.
[This message has been edited by dorbie (edited 01-13-2002).]
Yes introducing a clip plane on the 2nd pass, is a huge state change, and is most definitly the reason for your Z fighting.
what I have found, in my limited experience, is that I can get z fighting with exactly the same geometry using GL_EQUAL (although I almost always use GL_LEQUAL)
the only time this occured was when I was passing the geometry using glVertex calls… but I found the problem dissapeared completly when using arrays adn drawelements…
(this was a very long time ago, so I don’t have the buggy code that did it…)
I’ve also noticed with shadow volumes, using glVertex I get the odd stream running down the shadow, yet with compiled arrays I don’t… but once again. that was a while back. (which is a similar problem I guess)
You used a GL_EQUAL depth test in a multipass shader? I salute your heroic optimism.
Originally posted by dorbie:
PH, that is the test, not the fragment values which are created. There is a deliberate opt out clause in the spec for this. You can look for evidence to the contrary but it won’t change the spec.
Yes, you are right. I mixed it up with fragment generation.
User clip planes usually screw up multipass rendering - most of the time I use textures for implementing clip planes ( that should solve Bruno’s problem ). I’ve never had z-fighting in my own work ( even on a Voodoo3 with 6-pass shaders ).