I’m currently building a flight sim (www.web-discovery.net), and i actually use a 2048x2048 raw heightmap to generate the terrain to fly over. To keep a decent detail, the map is covering an area of about 30km x 30km (or about 19mi x 19mi), which is covered in less than 5 minutes of flight.
So, before i can have missions of about 30 minutes, i need to find a way to have a much larger terrain.
I know it’s not possible to load a whole heightmap of about 12288 x 12288 pixels (i.e. 6 times what is now), so perhaps there are other sort of solutions.
Maybe loading dynamically terrain from disk ? But how do i deal with 6 heightmaps ? When i approach the end of the first area, i should load the second from the hard disk, and it would take a considerable time and loss of performances.
Split your terrain into tiles and implement a caching system, I would have all tiles withing a certain distance in memory, as you move you would load new tiles into memory just before they are needed.
It supports caching/prefetching of large datasets…I have used it to render a large (about 1-1.5 gigs) terrain database…
I don’t know how well your approach fits into the framework, and this app may be way overkill for you as it does a lot of other things. Source is around 200k lines, I believe.
despite all tries to make roam play well with modern hardware id forget about it for now (especially the original version that will waste more time adapting the mesh than rendering would have taken).
the problem with geomipmapping is that for low resolutions you waste a draw call for 2 or 8 triangles. i think chunked lod would combine multiple patches into a larger one and keep the number of triangles per chunk up. drawback is less flexibility in lod selection (if one patch in the large chunk requires higher lod youre screwed) and id imagine making chunks match at the edges would be a bit more trouble (quick and dirty: all chunks use highest lod along the edge).
just like geomipmaps you can use one vertexbuffer and different index buffers (in this case even one per lod, as you dont care about linking pieces).
about loading new parts of the terrain: save most info in the file, so you dont have to start a calculation marathon when loading. use a seperate thread or (works, but results in an ugly mess codewise) load just a bit every frame. basically like a different thread, just as state machine thats spending a certain amount of time each frame loading a new part of the terrain.
Originally posted by Adrian: Personally I don’t think ROAM is a good solution for terrain engines anymore. Geomipmapping is better suited to modern hardware imo.
I agree on ROAM. It should be taken with some salt right now. About the so called “geomipmapping”, do someone noticed the fact the terrain needs to be huge?
I’ll be more specific. Say your terrain dataset is 21334x17053 samples and each sample height 16bits. Just putting everything in floats will eat away hundreds of MB of memory. Expand it to three components and you can easily hit over a GB of flying data. Add the extra data to use “geomipmapping” and you’re over what most people got in their PCs.
I agree with Adrian. An efficient caching subsytem with tiling is the only way to go for very large terrains. Geomipmapping could work great for small terrains but it’s definetly not there for large terrains.
well, geomipmaps and tiling dont exclude one another. all index buffers can be unique, as can be 2/3 of the vertex data. the remaining vertices (actually just heights) would be stored within each tile. though for this usage i might think about rather big tiles so there will be few enough to do culling per tile without needing a tree or anything on top of it. the minimum for 4096x4096 heightmaps i can reach is 16mb (without vbo, the alignment requirements would make it 64mb or damn slow).
one way or another, you need a fast way to load new parts of the terrain. for a flight sim a big scaling factor might be ok and would make it a bit less difficult to make it work well (as i assume the view distance shouldnt be too limited)