Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

strahan

Techniques for programming large terrains

This topic is 5481 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been reading a lot of papers on different techniques for programming large terrains. From ROAM, to CLOD, there are a lot of them out there. Of all the techniques which one is the best for displaying large terrains? What does everyone recommend? Also, does anyone know of any good terrain engines (possibly with open source)? Thanks! Mike

Share this post


Link to post
Share on other sites
Advertisement
If you mean large like 20 000x20 000 look forward into streaming the map. Lods and such are only to speed rendering, however the true cap lies in the memory.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Chunked LOD or GeoMipMapping are probably your best choises

look at www.vterrain.org for more info

Cheers,

Share this post


Link to post
Share on other sites
well, the real problems comes when terrain size is big, let''s say 4096x4096... what optimization you can do? Disk pageing is excluded, we need more FPS, not permanent disk read. If you make a simple computation 4096x4096xVertexDataSize (position[3],tu,tv,etc.) will see how many memory you need only for vertex data.

I agreed the real problem is RAM, lod algorithims work good and are eficient when you can hold some vertex buffers, making them on the fly or reading from disk is not a solution. I think in that moment ROAM rules the lod algorithms for large view distance, even are CPU intensive.

Share this post


Link to post
Share on other sites
quote:
Original post by ReType
well, the real problems comes when terrain size is big, let''s say 4096x4096... what optimization you can do? Disk pageing is excluded, we need more FPS, not permanent disk read. If you make a simple computation 4096x4096xVertexDataSize (position[3],tu,tv,etc.) will see how many memory you need only for vertex data.
I agreed the real problem is RAM, lod algorithims work good and are eficient when you can hold some vertex buffers, making them on the fly or reading from disk is not a solution. I think in that moment ROAM rules the lod algorithms for large view distance, even are CPU intensive.


You can hold for example higher LOD-s in the RAM, building VBs from them, and streaming when moving. You can store even the whole map like heightmap in RAM, and creating VB-s on the fly and on demand. What is the problem with 4k x 4k, I see none.

Share this post


Link to post
Share on other sites
The problem I have is storing the landscape. Heightmaps seem to be a good idea for smaller terrains. Is there anyway one could implement a really big world, without taking up too much space on the hard drive?
I was thinking about some sort of tiling algorithm, but that requires a lot of work.

Share this post


Link to post
Share on other sites
How about generating fractal on fly? I remember there was a thread about this awhile ago.

Still the problem is you can't store the map. You have to store the map. There is no single zipping algorithm.

[edited by - Captain Goatse on June 17, 2003 7:09:50 AM]

Share this post


Link to post
Share on other sites
The problem is I have to store the terrain somehow. Right now I''m thinking about creating lots and lots of tiles that could be placed on a grid. Perhaps some sort of noise algorithm could be used in the center of each tile to add some more realism.

Share this post


Link to post
Share on other sites
I''ve done a little system to handle 66x66km2 terrains with meter-detail with only a 17MBs file as storage (and this is raw data with ints and floats compression planned...). It can also run in a few hundred FPS with a view distance too far for any eye to see, but usually it runs at 300-500 FPS.
The trick was to make a "rough" heightmap and then generate details as needed. I adapted the pure GMM-concept to reduce vertex array-switching (something like Chunked LOD? Never investigated that too much, due to the pre-process and stuff).
Unfortunately, I can''t tell you too much about what I did, this code might be commercial in a while

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!