Jittery terrain mesh

I’m having an issue where as I rotate my scene individual points in my terrain mesh seem to move slightly causing a weird “jumping” or “jittering” artifact. I only notice this issue when the camera is less than 300 units away from the scene’s focus (and the terrain). Has anyone seen anything like this before or have any ideas about how to solve it?

The terrain is broken up into tiles which are drawn as triangle strips. The tiles are not being recalculated between draws, the points are calculated once and then redrawn whenever it is determined that they are on screen.

could it be that you are drawing your terrain multiple times and are experiencing z-fighting?

Just double checked and I am only drawing each terrain tile once per draw.

either your near-plane is too near, or your far-plane is too far, or a combination.

I just tried setting my near plane to 100 and my far plane to 105 and I’m still seeing the same behavior with the added side effect of the terrain at the top and bottom of the screen will disappear as I pan down. Is the difference between them still too big? I’m working with a model of the Earth so all of my points are really big (roughly 6,000,000 units away from the origin), is there any limitation on the size of the coordinates you use with GL?

i doubt, that it is the near and far planes, since you can rule out z-fighting. the precision of the zbuffer is afaik 24 bits, so you can set your planes pretty far away from each other.
eg. 0.1f and 10000f

i dont know of any dimension limits in OpenGL. but try rendering it with a glScale of 0.000001, zoom in with your camera and see if the problem persists or not.

I mentioned it, because the near-plane is often set to redicilous values, like 0.01 or even 0. But appearantly it wasn’t the issue here.

Unfortunately even with a scale factor of 0.000001 I can still see the problem. I’m going to try to create a smaller test case outside of my program that I can debug or post here, but if anyone’s got any other ideas I’d be grateful for them.

We stumbled across an article which was describing the exact same problem we were having: http://www.gamasutra.com/features/20020712/oneil_01.htm

So it seems like the scale of our numbers were causing some inaccuracies to creep into the GL matrices and the solution was to always position the camera at 0,0,0 and then to draw the terrain and models in that space. Using a glTranslated() call to move everything back didn’t work, the terrain had to be recalculated using an offset so that we could use smaller translates to move the terrain relative to the eye.

Thanks for the suggestions.

Ah… FYI, 32-bit floating point numbers have approx. 7 significant digits. (OpenGL doesn’t natively support doubles)

So when your objects are 99999m from 0,0,0, you can ‘only’ render with 1cm precision at the near-plane, quickly losing even more precision after that.

In your either your or the OpenGL matrix-math, there are numerous multiplications, causing this effect for much smaller numbers.