Shaky ground

I’ve been struggling with this problem for a few days now.

I have a terrain engine, if I rotate the view (acutally I rotate the terrain) the ground shakes, the triangle vertices wobble slightly but enough to be annoying. There is no wobble if the view is static.

I’m fairly sure its a precision problem. I have converted all my calculations to double but it makes no difference. I know glvertex3d converts doubles to floats before rendering.

I think up until I send the vertices to be drawn they are perfectly accurate. I cant see how I can correct this. I thought maybe it was to do with my vertex values being too small and getting clipped so I tried scaling all my values up by a factor of 100 but it made no difference.

My terrain is made up of 4096x4096 quads. Each quad vertex has a spacing of 1 unit. Each unit represents 200 meters. The view is set at 3 meters above ground.

Incidently I wanted the view to be 2m above ground but lack of Z buffer precision prevents me from doing this (without reducing view distance). Anyone know if a 32bit Z-buffer card is on the horizon… Matt

Here is a wobble free screen shot http://planet3d.demonews.com/NewMEX0011.JPG

Thanks for any help.

Very nice looking image! Is that satellite data?

It does sound like you’re pushing the envelope of precision a bit. Keep in mind that a floating point representation is has a hard time producing detail in a large scale – ie, you’re not gonna have too much luck getting small increments from huge numbers because the significant digits are spent elsewhere where they’re more significant.

Do you get the same problem if you’re viewing from higher up, or does it diminish? If it diminishes, it sounds like precision. If not, then maybe it’s elsewhere.

Do you only call Rotate or do you call other transforms as well?

Does it do the same thing in wireframe? Maybe you’re seeing texture problems rather than geometric problems?

Those are my only guesses.

The dataset I am using was created from half a billion height points of Mars collected by MGS.

The problem disappears when viewing from higher up.

I call rotate3d and translate3d.

The same thing happens in wireframe.

I think it is precision like you say but Im a bit surprised because floats are 4 bytes so can hold 4 billion different values. So with 4096 units it should be possible(in theory) to get precision of 1 millionth of a unit which is .2mm in my case Even a precision of 10cm would stop the wobble. So it looks like a lot of precision is being wasted and Im wondering if there is a way of using more of it. I cant see how though.

you know, in floats the precision is very good for small values, means 1.003 and such can be stored nicely… but if you have values around 1000 or 1000000, its not the same precision anymore…

its not a linear precision… and like that you can get large problems for farfrom (0,0,0) points…

this you can see if you have a floatingpoint timer… after some time you simply are at the precision of seconds… if you just add the values… and this is not so precious then for updating the frames with it

what you could do against?.. dont really know…

Do you notice ANY difference between Float and Double? If not, then maybe the double isn’t taking for some reason. You might try making your own view matrix and passing it rather than relying on the card to be kind to your data. Dunno if it’ll make a difference, but might be worth a try.

time for some wild stabs in the martian dark!

If you pull the depth range in (which will create popping) does it effect the wobble?

Maybe the data is fine but the change in values you pass for rotation and/or translation are in error ??

If you move the viewpoint rather than terrain does it still wobble?

If you post a demo I’ll gladly test it on my Geforce3

ta ta

Rob J.

Your values all seem within reason to me. I don’t think, given your database, that you should be having a precision problem with either depth buffer or rotations.

1. Are you transforming them all with the same modelview matrix? By this I mean no translates or rotates inbetween drawing vertices?

2. What is the actual range of floating point values that you are using? 0.0 - 4096.0? Try not multiplying this by 200 if you are…

3. About depth…the number of different depth values that you could possibly have would be something like 4096 * sqrt(2). Aren’t most depth buffers 16 bit? That’s like 65000 unique values. Try decreasing your far frustum plane or increasing the value of your near frustum plane.

That screenshot of yours looks really good

– Zeno

Thanks for everyones replies:

davepermen
My vertex values are always les than 4096.

mv
There is no difference in the amount of wobble between using floats and doubles. Maybe I should do like you suggest but I’m fairly sure the problem isnt with creating an accurate modelview matrix but how it is processed afterwards.

pocketmoon
Changing the depthrange has no effect on the wobble. I need to check out your other 2 ideas. I will post a demo in a couple of days, thanks for the testing offer.

Zeno
All transformations are with the same modelview matrix, except the skydome but that shouldnt effect anything.
The range of values Im using is 0 - 4096.
I’ve tried reducing the far frustrum plane but that had no effect. Increasing the near plane I could try but I will not be able to stay as close to the ground otherwise the ground will get clipped. So there would be less wobble but I am no longer 3 meters off the ground.

Here is my modelview code

glMatrixMode(GL_MODELVIEW);
glLoadMatrixd((GLdouble *)transform);

glRotated(viewz,transform[0][2],transform[1][2],transform[2][2]);
glRotated(viewx,transform[0][1],transform[1][1],transform[2][1]);
glRotated(viewy,transform[0][0],transform[1][0],transform[2][0]);

// Save model matrix as transform
glGetDoublev(GL_MODELVIEW_MATRIX, (GLdouble *)transform);

I know its not recommended to repeatedly rotate the same matrix with small increments like this but I tried rotating the identity matrix and got the same wobble.

I then use the following code to move the terrain.

glMatrixMode(GL_MODELVIEW);
glLoadMatrixd((GLdouble *)transform3);
glTranslated(XPos,YPos,ZPos);

and this is my projection code:

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(40+ZoomAngle,ASPECT,CLIPNEAR,((FOGEND+FOGBUF)-YPos));

where FOGEND+FOGBUF=1200
and CLIPNEAR is set to 0.01 for 24 bit z buffer and 0.25 for 16bit

I’ve fixed it!

I noticed when I flew over vertices around 0,0 there was no wobble, moving to the other side of the map 4096,4096 it was really bad.

So the problem was to do with translating large values(over 1000) and then rotating. Strangely scaling everything down by a factor of a 100 didnt fix it.

Although the landscape polys wobble, the really noticeable wobble was the detail textured polys close to the viewpoint. So before drawing the detail polys I replaced

glMatrixMode(GL_MODELVIEW);
glLoadMatrixd((GLdouble *)transform);
glTranslated(XPos,YPos,ZPos);

with just

glMatrixMode(GL_MODELVIEW);
glLoadMatrixd((GLdouble *)transform);

and then offset the vertices for the polys by XPos,YPos,ZPos.

Its steady as a rock now

Here’s a link to my demo. Its just a terrain engine but you get to fly over an accurately rendered Mars.
http://planet3d.demonews.com/MarsExplorer.zip
(10Mb)

It’s a Tnl monster, 250k polys per frame, so you’ll need a Geforce to get a decent frame rate. Previous high poly apps I’ve written have run slow on detontators pre 10, not sure if the same applies to this one.

For more details check out the readme in the download.

I’m interested in performance on the Geforce 3. I dont expect it to be much better than on a GF2.

If you have a GF3 heres a link to a high res texture (4096x4096), I havent seen it running with this texture coz Im still waiting for my GF3 to turn up.
http://planet3d.demonews.com/Labyrinthus4096.zip
(12Mb)

Heres another screenshot http://planet3d.demonews.com/NewMEX0002.JPG

Adrian -

I gave your program a try. Here are some comments, in no real order.

1. It caused an access violation when it said it was loading textures until I downloaded the high res texture and put it in the same directory.

2. It ran really slowly. Like ~1 fps on my PIII-450 and Geforce 3. Only getting like 0.05 M tris/sec. Doesn’t this seem weird?

3. It looks like it would be really beautiful if I could stop the spinning of the viewpoint and have a smoother framerate. Maybe you could make it so that the mouse doesn’t turn you automatically based on where it is? It was impossible to center the mouse in full screen at 1 fps, since there was no mouse cursor drawn.

4. It seemed very foggy…

If you want me to help with any more testing, just ask

– Zeno

Originally posted by Zeno:
[b]Adrian -

I gave your program a try. Here are some comments, in no real order.

1. It caused an access violation when it said it was loading textures until I downloaded the high res texture and put it in the same directory.

2. It ran really slowly. Like ~1 fps on my PIII-450 and Geforce 3. Only getting like 0.05 M tris/sec. Doesn’t this seem weird?

3. It looks like it would be really beautiful if I could stop the spinning of the viewpoint and have a smoother framerate. Maybe you could make it so that the mouse doesn’t turn you automatically based on where it is? It was impossible to center the mouse in full screen at 1 fps, since there was no mouse cursor drawn.

4. It seemed very foggy…

If you want me to help with any more testing, just ask

– Zeno[/b]

Thanks for trying it out Zeno,

Could you try this exe, it will scale the texture down to 2048x2048 but it will be interesting to see if it speeds it up. You should be getting at least 15fps.
http://planet3d.demonews.com/MarsExplorer2.zip

The fog can be reduced by pressing ‘Y’

The viewpoint will be easier to control when the frame rate gets better

The access violation is a bug in my code and will only occur for gf3’s, I will look into that tomorrow, its getting late here in the UK.

Wow, did that ever make a difference!

I didn’t realize it before, but the texture was not appearing before and the landscape was all black - only the fog was giving it color, which is why I said there was too much fog.

It looks great now, just like your screenshot.

Here are some (maybe) useful approximate stats:

Max detail: 10 fps, 7 Mtris/sec
High detail: 12 fps, 5.5 Mtris/sec
Medium detail: 15 fps, 5 Mtris/sec
Low detail: 25 fps, 4.5 Mtris/sec

This is all at the default window size with 32 bit color. The speed was very much geometry (probably CPU) limited, as maximizing the window to 1600x1200 didn’t phase the frame rate.

Nice demo

– Zeno

This is slightly off topic but anway:

I am curretnly using worldcraft to generate some test data for my engine (until I finish my editor). The data is all scaled to ease texturing (i.e. to the power of 2, 128,256 etc.) these are all ints but I found that I was loading them as floats, data range was about >10,000 units. I noticed that there were many gaps in the geometry at certain points (point of a cone etc.) - could this be because of inacuracies, would changing to int (should do this anyway) improve this. Would there be any advantage to re-scaling down to values that easily fit in floats.

p.s the picture looks very nice, wont bother downloading it wioth my tnt2 m64.