Atlas - water jitters at flat shoreline

#1 Actually, I think it's the water reflecting the underside of the terrain, and since when you view the terrain from underneath you're viewing the back-side of single-sided polygons, it winds up reflecting the sky, but I could be wrong.

Sorry, maybe understanding the problem might lead to a solution, but I have no idea how to solve that problem. Maybe making the waves only go up and not down might solve it?

#2 I haven't seen the problem, but maybe it's just zfighting? You might be able to fix it by playing with the zbias. But it seems like the easier solution would be to just drop the terrain off right at the border between the land and water. That should minimize the issue.

#3 It's because the z-buffer only has limited precision, and it can't resolve co-planar polygons properly. (When the jitter happens you can often see a stairstepping effect, as the Z values change over the surface of the polygon - first one goes to a value, then the other, then the first again, back and forth, and you end up with a lot of ugly artifacts.)

The simplest fix is to reduce the far distance of your screne. The next simplest fix is to not make your geometry that way. :P The third simplest fix would be to make water draw always on top (no z test) without regard for sort, or artificially raised, but that can break down. The fourth simplest would be to fudge Atlas a bit to make the intersections with the water steeper.... There's lots of workaround fixes, but nothing that really resolves the problem that I can think of off hand. You'll notice that even games like Far Cry have this problem (or workarounds to it).

This unfortunately makes beaches a little trickier, without additional trickery of your own. Brian and I will probably come around to look at this problem at some point but it's not our first priority.

#4 Thanks Ben, I'll look into those solutions, although I think steeper terrain sounds like the only solution. Changing the z-test on the water sounds like it will create other problems (characters half submerged in water for example).

EDIT: By the way, you are talking about the far clipping plane, not Torque's visable Distance, right? (changing the visable Distance to 10 had no effect).

Although making the water move up and down like the legacy water might hide the problem as well. This shouldent be very difficult for a shader to do.

Here is some screenshots just so everyone else knows what we are talking about. I know it's kind of silly to try and take screen shots of jitter, but here is the best example of what I could get.
This is a screenshot from the exact same point with the camera angled in a slightly different direction. Notice how jagged the shorline is and how it changes from one viewing angle to the next. This happens constantly as long as the viewing angle is changing (It stops when the camera stops).

#5 Get FRAPS... it let's you capture video.. Good tool for developers.

#6 Dont really need fraps, I bet the developers already know about this bug as it is pretty obvious.

#7 @Andrew - ah, good point. I thought the far clipping plane was set to be near the vis distance, but I guess I'm wrong! :)

Basically the bigger the difference in order of magnitudes for your clipping planes, the more likely it is you'll see z-fighting issues. Having a very short near plane in particular can make MAJOR problems.

#8 Hi all,

Sorry to bump an 18-month old thread, but a lot of our current project takes place very high above the terrain and having jittery water where it intersects the terrain is really bugging me!

Did anyone come up with a fix for this? I'd be very interested to see if / how people are getting around it.

Thanks as always...

#9 As it turns out, what we ended up doing is actually pushing the near distance further out... (e.g. from 0.001 to 0.1 or similar). After looking up the z-buffer calculations, turns out they aren't linear and are more precise towards the front (probably obvious to some gurus). When we brought the near plane further out it fixed the jitter, of course now we have to deal with the near plane clipping through objects, but I think that is more workable then the depth problems. I changed the near plane value in the GameProcessCameraQuery function, I actually added a mNearDistance and getNearDistance() to our sky so I could play with the values in game and see how it affected the jitter and what not.

Hope it helps.

#10 I think Tom Spilman had a hack for this where he pushed Atlas vertices around when they were close to the waterplane.

#11 Stefan is correct... i did do a hack to that affect. I've been lurking this thread and haven't had time to collect my changes and post it.

The technique needs some refinement, but it helps things some... it sure isn't the best solution. It usually requires the terrain be moved by a meter or more. And because of that if you look closely at it you can seen artifacts... like distant objects sinking into the ground a bit as the terrain is lowered and having a strange boxy look to your shoreline.

I prefer the movement of the near plane as a better fix when you can do it. I just haven't thought of a good way to dynamically move the near plane based on what is in view. Possibly rendering the first person player/weapon/vehicle with a different near plane than the environment. If someone solves it in that way i think it would be a much better overall solution to the problem.

#12 Is it valid to change the near and far planes in the midst of rendering though? Seems to me that you would be comparing depth values that no longer relate to each other right? If my near plane for one object is 5 and for another object 10, then wouldn't both 5 and 10 meters read as the same value pixel wise for the two objects?

#13 Thanks for all the suggestions - I'll certainly look into them. However, am I right in thinking that this only manifests itself when we are looking at a shoreline (i.e. if I have a cliff face we don't see the problem)? That certainly seems the case.

I don't *actually* have a need for a shoreline. In theory my island could be surrounded by cliffs so that would be a nice easy solution :o)

I'll look at all the above solutions, however, and after our next meeting where we hope to finalize the design of the island I'll know which way I am going with this.

Thanks again all.

#14 Another option btw. is to actually simply cull out any of the atlas polygons underneath the water line (so essentially you get a clipped terrain clipped to the water plane), that way there should never be any Z values to fight against.

It depends if you need transparency on the water for that to work.

It would also be wise to alter the water code to allow a "fringe" at the clip line to extend out from the shore (so you get a skirt of foamy waves).

#15 That would be really neat. If someone does improve this can you please post your results somewhere? I had this (water shorelines) on my list of things to look at in the future.

#16 Old thread here.... but i thought i'd connect the dots for anyone looking for a solution to this issue.

I've posted a screenshot and a description of a technique that fixes this really well over here.