-1

I have an issue with the water in my terrain, which is currently just a quad with a transparent blue colour.

When close up to it, it looks like this: enter image description here

As you can see, it's simple enough - A flat transparent quad representing water.

However, when I get further away, this happens: enter image description here

For those who can't see the GIF, or need an external link (or can't understand what's going on), the terrain is glitching around the water. If you look near the water near enough, you will see the terrain glitching above/below it.

Here is the code where I prepare the 3D view:

static void ready3D()
{
    glViewport(0, 0, Display.getWidth(),Display.getHeight());
    glMatrixMode(GL_PROJECTION);

    glLoadIdentity();
    GLU.gluPerspective(45, (float) Display.getWidth()/Display.getHeight(), 50f, 500f);

    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();

    glDepthFunc(GL_LEQUAL);
    glEnable(GL_DEPTH_TEST);
}

Does anyone know what the issue is, and how I could improve the precision of the depth buffer (presuming the depth buffer is the issue)?

Joehot200
  • 1,070
  • 15
  • 44

2 Answers2

2

It's difficult to tell from the GIF, but what I'm gathering is that you're experiencing an instance of Z-Fighting.

There are several solutions that tend to be most effective for dealing with Z-Fighting:

  • Increase the Resolution of the Z-Buffer.
  • Adjust the relative positions of the Water & Land to separate them further, thus reducing the chance of the two geometries colliding like this
  • Make use of the Stencil Buffer to ensure that objects are drawn correctly.

I've also seen solutions that try to disable Depth Testing when handling certain objects, but those are almost never good as a general solution.

Xirema
  • 19,889
  • 4
  • 32
  • 68
  • 1
    Yes it seems like z-fighting. Assuming landscape is generated procedurally i think enhancement your generation algorithm so height values are not too close to plane is the most applicable solution. Resolution of z-buffer or using logarithmic z-buffer doesn't seem a good choice there as soon as plane can change height a lot and has great field of view. Can't say about stencil buffer. – Ramil Kudashev Oct 05 '15 at 16:32
  • @mlkn Could you please explain the advantages or disadvantages of changing the resolution of the Z-Buffer, and why me moving around would cause an issue? It seems like the simplest solution, and yet I don't know much about it nor how to actually implement it. – Joehot200 Oct 05 '15 at 16:51
  • 1
    +1 for the option of changing the way terrain is generated. This is "free" and doesn't add any computational complexity that using a stencil buffer would have. When generating the terrain, it wouldn't take more that 'if(y < 0) y = -100;` In other words, if Y is less than the level of the water _even a little bit_, make it way less than the water. – JPhi1618 Oct 05 '15 at 18:27
1

Increasing depth buffer wouldn't help a lot as having an open world causes a big distance from zNear to zFar which maps to your depth buffer. One of common tricks is implementing logarithmic depth buffer. This gives you an ability to accent where do you need details but in current situation this need changes with altitude of your vehicle+camera system. So logarithmic buffer is not a solution and increasing "linear" buffer wouldn't affect a lot. I recommend to read this and this awesome articles about depth buffer.

Second point is that your landscape seems procedurally generated. If it is so vertices could spawn really close to water plane height. And winning in this floating point comparison war is not simple with just depth buffer manipulations (if possible at all).

Third point is that in general you don't want extra runtime job and that's the reason stencil buffer usage is questionable here (As JPhi1618 noticed).

So if you have an opportunity to modify your landscape generation algorithm from my point of view it is worth it. From JPhi1618 words again:

if Y is less than the level of the water even a little bit, make it way less than the water.

Community
  • 1
  • 1
Ramil Kudashev
  • 1,166
  • 3
  • 15
  • 19