Terrain Optimization...

[zix99]

Hi all

I was wondering what some different methods of optimaztion could be used in drawing terrain. All i have heard of is Tesselation, and a method where the farther out the poly is, the bigger it gets, thus reducing the poly count. The second methos i said works very nicly, but when i do per-vertex lighting it starts looking very bad.

Thank you for any ideas and suggestions
Zix

p.s. i am using very large terrain (2000x2000) to (4000x4000) units

[Machiavelli]

Visit Google.com with the search phrase 'ROAM'

Good luck.

[JustHanging]

Don't use per-vertex lighting...

-Ilkka

[bunny]

Geomipmapping is better suited to current hardware than ROAM. Google will reveal more.

[Ostsol]

I agree on the per vertex lighting, thingy. Set all the vertex normals to face straight up and use a normal map, just like if you were doing bump-mapping on a flat surface.

EDIT: In my own terrain renderer it was even worse since I was using per-vertex colouring instead of using a colour map. Hehehe. . .

[This message has been edited by Ostsol (edited 08-12-2003).]

[JanHH]

what's wrong with per-vertex lighting?

[Ostsol]

Originally posted by JanHH:
what's wrong with per-vertex lighting?

When you bring the terrain down to a lower polygon count you have less vertices to work with. As a result, you lose alot of the finer detail in the shading (in addition to the loss of polygon detail). By using a normal map, the only detail you really lose in in the terrain's sillouette -- and a good tesselation algorithm can minimize that, anyway.

[Obli]

Originally posted by bunny:
Geomipmapping is better suited to current hardware than ROAM. Google will reveal more.

I am not really sure of that (reading about Geomipmapping right now). I agree that there are algorithms avaiable which works nicely when "small enough" terrains are getting rendered but here zix is using a 4000x4000. I am also doing a large terrain renderer and most algorithms around the net does not feel attractive (my crash test is 12000x8000).
Now, the terrain map itself is, for zix 4000x4000 = 15.2MB if he's using 8bit samples. Expand that to a 16bit only and 30MB are gone away (for height only). Add eventual GeoMipMaps and stuff like that. I feel there is the need to manage memory very effectively here.

I must thank you anyway for the hint provided about geomipmapping. I am very interested on that topic. I'll keep an eye on it (reading a paper right now).

[Adrian]

I would recommend what I think is being called,'chunked LOD'. I presume it's not the same as geomipmapping or is it?

Basically break your terrain up into chunks e.g. 128x128, then calculate the LOD based on distance from the viewer.

You can use a cacheing system to only store the vertex array data for visible chunks of vertices. You only need to regenerate the vertex data when a chunk becomes visible or changes LOD. This keeps memory/cpu usage low.

This is imo the fastest,most memory effecient way of rendering terrain on modern hardware.

This screenshot shows a wireframe view of chunked LOD terrain with a 4kx4k dataset. http://www.adrian.lark.btinternet.co.uk/MarsExWF.JPG

Edit: Image updated to show newer version of the software running at 51MPolys/sec. With fog off it runs at 82MPolys/sec on a GF5900u)

[This message has been edited by Adrian (edited 08-12-2003).]

[bunny]

Originally posted by Adrian:
I would recommend what I think is being called,'chunked LOD'. I presume it's not the same as geomipmapping or is it?

Basically break your terrain up into chunks e.g. 128x128, then calculate the LOD based on distance from the viewer.

You can use a cacheing system to only store the vertex array data for visible chunks of vertices. You only need to regenerate the vertex data when a chunk becomes visible or changes LOD. This keeps memory/cpu usage low.

This is imo the fastest,most memory effecient way of rendering terrain on modern hardware.

This screenshot shows a wireframe view of chunked LOD terrain with a 4kx4k dataset. http://www.adrian.lark.btinternet.co.uk/MarsExWF.JPG

Exactly the same idea.

I'm currently working on a variation of this, where the patches are stored in quad-tree nodes, and all are the same fixed resolution. The advantage of this is that the fixed chunk size is the optimal amount of vertex data to send to the graphics card in a single burst. Although it's not as flexible as the standard approach.