I know this is sortof a n00b question, but I figure the worst that can happen is public ridicule
Suppose I have a large terrain database, and now have to put a water plane in at sea level. Of course, no matter what your depth buffer precision, this is going to cause z-fighting in some areas where the shore is nearly the same slope as the water.
Is there any way to avoid this without doing much modification to the database (i.e. I can’t cut the database and add water vertices at sea level) or greatly increasing rendering time (using a clip plane to do underwater terrain first, then draw the water, then do above water with a reversed clip plane)?
Can you explain a bit more? Doesn’t that just perturb the depth values a bit (by a constant + a factor dependent on slope from viewer)? If so, won’t it just move the spots where the plane z-fights with the terrain?
Your landscape is integer height-map based I guess? Why not make sure that the water is half-way between two descreet land height values so that land and water can never be at the same level.
In other words, there will never be flat land at the same level as your water.
You would only have a problem if you have a very long slope that is almost flat.
If that is your problem, then I may have a solution if PolygonOffset does not work. You could stretch your artwork along the z axis, centered on the water level plane, to increase the slopes. This way all your land will still intersect the water at the same point. You would render this stretched land only to the z buffer, then you could draw your water to the stencil buffer, setting the stencil where if passes the z test, then draw the water into the stenciled area.
I think it would work, but you have to draw everything twice.
Originally posted by Nakoruru:
Your landscape is integer height-map based I guess? Why not make sure that the water is half-way between two descreet land height values so that land and water can never be at the same level.
Nakoruru: You’re a genius! At first I didn’t think it would work, as the data I get uses 16 or 24 bits to store the height values (not 8), but I was still able to place the water at an intermediate height and it all but eliminated the z fighting (except in the far distance where the buffer is less precise). It’s so simple I can’t believe I didn’t think of it.
