Terrain (Geometry Clipmaps) and Data Loading

Started by
1 comment, last by Boruki 12 years, 5 months ago
Hi everyone,

I've been working on a small personal project for a long time now and a while back I stumbled across Geometry Clipmaps for terrain rendering. I've (very slowly) been getting my head around how it all works on the rendering side of things. However I'm having some issues deciding how to produce the data from which to render my terrains. I've had a lot of different opinions on the most suitable approach and so I figured I'd come to a good source of facts and opinions!

I've mostly been focused on a large set of "chunked" files, all of these stored at the different resolutions that I might need. So if there are 9 levels display, then I'd have the entire terrain stored in 9 different sets of chunks, each in its own resolution.

Another idea I had was to just access one large file, but I'm not sure how suitable this would be considering the scale of the game world. For each of the higher levels (lower resolutions) I'd need to do checks at intervals, rather than every point. Is the searching time required by this going to be a big overhead that makes it impossible?

Also someone suggested just using a custom file format system, each file containing either a specific areas data for all levels or maybe all the data for one specific level?


As is probably quite obvious, I'm getting myself a bit confused a muddled with all the ideas. So please, any ideas (especially any that you guys have got working yourselves) are eagerly awaited!

Thanks!
Advertisement
Start with single files for each patch. That is , the lowest resolution (whole map) should be stored in a single file, at each resolution store each patch in a single file too. The next step would be to use some kind of virtual filesystem, i.e. put all files into a single zip file from which you stream your terrain. Loading and seeking time should not be a problem when using asyncrous loading and some kind of cache. Every file should have the same unpacked size, so a nice LRU - cache or some kind of virtual memory approach should work like a charm.
The first solution you mention there is roughly what I was originally considering.. I guess I really am going to need to learn a lot more about loading on the fly and the torodial array stuff that was mentioned.

This topic is closed to new replies.

Advertisement