Z-fighting ?

Started by
5 comments, last by GLForce 14 years, 12 months ago
I am currently programming a simple 3D engine and currently I'm working on more "advanced" features such as terrain. Now here is the problem, I've just added a water plane and on the intersection between this plane and the hills from my terrain, bothering "jaggies" appear. I've put a screenshot. http://img232.imageshack.us/img232/6866/jaggies.jpg I thought it could be the pixel shaders (there are pixel shaders applied on both the terrain and the water), but after quick tests I came to the conclusion that it was not. I've tried also to replace the indexed primitive rendering used for the terrain by normal primitive rendering, and still got the same result. So, my conclusion is that it may be a z-fighting problem. Am I right ? It seems kind of logical because at the particular point where the water plane and the terrain slope meet, the pixels are at the exact same position. So if it is really z-fighting, is there any simple soluion in that case ? The only solution I found myself was to make a custom shape following (but not crossing) the shoreline for the water plane, but it adds alot of useless work and removes alot of freedom. Any thought ? Thanks !
"Do, or do not. There is no try." - Yoda
Advertisement
It does indeed look like some pretty serious Z-fighting.

At a guess, I'd say your near and far clip planes are probably too far apart. In particular, try moving your near plane out further from the camera and see if that helps.

You might also check what depth precision you're getting; if you're using a 16-bit depth buffer you could switch to 24.
Orin Tresnjak | Graphics ProgrammerBethesda Game StudiosStandard Disclaimer: My posts represent my opinions and not those of Bethesda/Zenimax, etc.
It worked, thanks alot. WHat I find odd is that I read somethign about the distance between clipping planes and so I tried to get the Far Plane closer to the camera. It didin't work. However, just pushing the near plane a few clicks forward made it. I don't understand quite well, as it seems the distance is not important, but it's more like the near plane position. Anyway, problem solved, and very quick, so thank you again.
"Do, or do not. There is no try." - Yoda
Definitely z-fighting.

As your water and terrain head to the intersection there simply isn't enough resolution to express the differences. I've seen this quite a few times in terrain engines I've written [grin]

Have a look at depth biasing as it may offer a simple solution. If you render the water last simply apply a bias to it and fingers crossed you'll be fine!

Just be careful as depth biasing can have different results on different hardware [headshake]


hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Quote:Original post by GLForce
I don't understand quite well, as it seems the distance is not important, but it's more like the near plane position.
Have a read of Learning to Love your Z-Buffer. It's in the context of OpenGL but otherwise sound.

Basically Z-Buffer's are non-linear in nature which affects the distribution of integer depth values as stored in the buffer itself.

Its one case where simply going from 16 to 24 may not make any difference as an extra 8 bits still might not give you the precision where you need it!


hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

I just tried depth biasing and it doesn't seem to work. Like you said, resuolts may vary on different hardware and it seems it won't work on mine. Anyway, the problem was already solved by putting a near plane distance of about 5, which isin't much but still gives the wanted results. Thanks anyway !
"Do, or do not. There is no try." - Yoda
Quote:
Have a read of Learning to Love your Z-Buffer. It's in the context of OpenGL but otherwise sound.


Now I get it. I always thought (and I guess I'm not alone) that the z-buffer was linear. Of course it's more logical to do it non-linear, but well, I guess that's why I'm not the guy who thought those concepts :P It's always good to undertsand a bit more what I'm doing. Thanks.
"Do, or do not. There is no try." - Yoda

This topic is closed to new replies.

Advertisement