Strange terrain problems

[AW999]

I had adapted Egon Olsen's terrain demo so that it uses my own procedurally-generated terrain and water, but I ran into two odd problems:
 1) occasionally there are random polygons which are stretched out of position, so that one vertex is in the wrong place and the whole poly is therefore elongated to a random point on the map. At first I thought it was a problem with my terrain generation algorithm, but the problems are random.
 2) Low-lying terrain at or near a Y coordinate of 0 allows you to see part of the water plane underneath, even if I lower the water plane to -3 or -5 etc; there is still a patchwork pattern of water showing through in many spots, and the problem increases as the viewer position elevates.  The original terrain demo didn't have this problem.

[EgonOlsen]

The first problem can have several reasons:

a) you are modifying the mesh in another thread without proper synchronization with the rendering
b) it can be a driver issue
c) it can be a hardware failure, i.e. a weak memory cell on the graphics card. I had the same problem with my old ATI 9700.

Do you have a screen shot?

The second problem might by an accuracy issue of the zbuffer. Screen shot?

[AW999]

The first problem can have several reasons:
a) you are modifying the mesh in another thread without proper synchronization with the rendering
b) it can be a driver issue
c) it can be a hardware failure, i.e. a weak memory cell on the graphics card. I had the same problem with my old ATI 9700.
Do you have a screen shot?
The second problem might by an accuracy issue of the zbuffer. Screen shot?

  For the second problem, here are two screenshots:
These are both overhead views from some distance above the terrain, since the problem increases with viewer elevation.
Notice the streaked patterns, which fluctuate as you move the view.

Here's the second one:


It's more difficult to get a screenshot of the 1st problem (triangles which are occasionally stretched to random points) since it seems to occur completely at random and hence is difficult to reproduce.

[.jayderyu]

Well maybe part of the stretched triangles have to do with the procedural generation. I assume that if your creating the land in memory it's a an array

• [y]. Where as Egons sample is a file. So what could be wrong is the the associated hieght.

list the code that shows the the creating or setting of your terrain. I user the vertex controller and set the height of pre created plane. It's slow though.

[EgonOlsen]

The screen shots show z-fighting, i.e. the zbuffers accuracy isn't high enough to separate the ground and the water, because they are too close together. The reason why this increaes when moving the camera further away is, that on most hardware actually not z will be stored but a/z (with a being some scalar). That's pretty accurate close by but the inaccuracies increase if z increases, i.e. accuracy isn't linear in camera/clipping space.
You may try different things: a) Move the water away from the ground. b) Decrease the far clipping plane. c) set Config.glIgnoreNearPlane to false (the docs of this switch are reversed, i'll correct this) and increase the near clipping plane (this will move the scene close too the camera...so don't increase it too much, or you'll end up with a very distorted scene).

The random polygon seems to be a driver (unlikely) or a hardware problem (more likely). You can play around with Config.glBatchSize and Config.glDynamicBatchSize to see, if this changes anything. Which graphics hardware is that?

[AW999]

The screen shots show z-fighting, i.e. the zbuffers accuracy isn't high enough to separate the ground and the water, because they are too close together. The reason why this increaes when moving the camera further away is, that on most hardware actually not z will be stored but a/z (with a being some scalar). That's pretty accurate close by but the inaccuracies increase if z increases, i.e. accuracy isn't linear in camera/clipping space.
You may try different things: a) Move the water away from the ground. b) Decrease the far clipping plane. c) set Config.glIgnoreNearPlane to false (the docs of this switch are reversed, i'll correct this) and increase the near clipping plane (this will move the scene close too the camera...so don't increase it too much, or you'll end up with a very distorted scene).

   I had increased FarPlane, but decreasing it back to the original value didn't help things any. The other options don't look feasible.
 Would setSortOffset have an effect? 

[EgonOlsen]

No, setSortOffset() doesn't have an effect. Why isn't increasing the distance between ground and water surface an option?

[AW999]

No, setSortOffset() doesn't have an effect. Why isn't increasing the distance between ground and water surface an option?

   As in your original terrain demo, the water plane has to intersect the terrain at various points to form the shorelines for lakes, and of course the distance between the two surfaces is going to be fairly small near the shorelines.

[.jayderyu]

From what i'm seeing of your screen shots. It looks like the ground plane is near the same height as your water. Increase the elevation of the vertex points so the terrain is more terrain'y with hills, mounds and lake/river drops. Then see if there is the same graphical problems. As it is, it just looks like the ground is too close to the water which is causing the graphical problems.

[AW999]

From what i'm seeing of your screen shots. It looks like the ground plane is near the same height as your water. Increase the elevation of the vertex points so the terrain is more terrain'y with hills, mounds and lake/river drops. Then see if there is the same graphical problems. As it is, it just looks like the ground is too close to the water which is causing the graphical problems.

  The screenshots show low-lying land near shallow lakes, but there are also hills and deeper lakes in other parts of the terrain.  I need to have both types of landscapes to be realistic - there are plenty of flat areas of land in real life.
  I can partly solve the z-conflict problem by replacing the water-plane with 'local' water polys only in those areas in which the water is above ground level;  but that would still cause shorelines to flicker. Surely there must be a way to get rid of the problem - there are plenty of programs which clearly use intersecting land and water planes to produce shorelines, without any flickering.

[EgonOlsen]

As i've already said above, you can try to increase the near clipping plane, albeit this might not help much in the distance. And ensure that you are really getting a 24bit zbuffer at least...this should be visible in the log at initialization stage.
Apart from that, i don't see many options left. If the accuracy isn't high enough, it's simply not high enough. There's no magic switch to increase it.
Which graphics hardware are you using and how is your water plane build? Is it one large quad or more tessellated? If it's one large quad, i may help to tessellate it some more.
If you look at my terrain demo, you'll notice slight z-fighting too if you move further away. I've just adjusted the far clipping plane and the fog in a way, it's not that noticeable.

[AW999]

As i've already said above, you can try to increase the near clipping plane, albeit this might not help much in the distance. And ensure that you are really getting a 24bit zbuffer at least...this should be visible in the log at initialization stage.
Apart from that, i don't see many options left. If the accuracy isn't high enough, it's simply not high enough. There's no magic switch to increase it.
Which graphics hardware are you using and how is your water plane build? Is it one large quad or more tessellated? If it's one large quad, i may help to tessellate it some more.
If you look at my terrain demo, you'll notice slight z-fighting too if you move further away. I've just adjusted the far clipping plane and the fog in a way, it's not that noticeable.

  I tried increasing the NearPlane value back to the original value in your terrain demo (100), but that didn't seem to make any difference. I also tried tessellating the water plane more by quadrupling the number of quads to 80x80, but that had no effect other than slowing the framerate to a crawl.
I don't think it can be the hardware, since Wurm Online doesn't have any flickering shorelines on my machine despite clearly using intersecting land and water planes. (Correction: Wurm does have flickering shorelines on my machine)
I wasn't able to confirm whether it's using a 24bit zbuffer; where in the log should it give this information?