Author Topic:   Paging terrain data
posted January 19, 2001 03:01 AM         
Is anybody working with very large terrain (> 2k x 2k)? I was thinking
along the lines on how I would handle texture and heightmaps.

Heightmaps, power of two:
1k x 1k = 1MB
2k x 2k = 4MB
4k x 4k = 16MB
8k x 8k = 64MB

For large heightmaps, I could probably use Windows file mapping. This
way, instead of copying the heightmap into an allocated buffer, I could
simply access the data directly as a file mapping. This sounds like it
could work very well.

For textures, since there is only a limited amount of video memory in
hardware, I would have to page in terrain texture when it is needed.
If I synthesize a single texture for the terrain, I could save it to
file first. Then I can access it with file mapping.

If each heightmap cell is exactly one texture pixel, the required
storage for a single 32-bit texture would be huge:

1k x 1k x 3 = 3MB
2k x 2k x 3 = 12MB
4k x 4k x 3 = 48MB
8k x 8k x 3 = 192MB

Any thoughts?


New Member
posted June 12, 2001 11:18 AM            

I think that if you want to perform window file mapping, you'd better store your heightmap as a set of patchs instead of a linear buffer. As if, your patch class will have a member pointing to the corresponding file position.
Only visible patches will be loaded in memory. And if your camera don't perform teleportation, you will only have a small set of patches to load from file every frame.


posted June 12, 2001 11:30 AM         
Texturing - TM's terrain texturing works with Vertex-based textures - that way you could calculate your texture layout on the fly (although I don't believe TM does that from what I've seen, no matter what other people say) based on height/angle ranges.
Since each texture only has to be large enough to cover one Triangle in your Heightmap, you could save lots of memory that way.


posted June 15, 2001 11:52 PM         
I haven't looked at my terrain code in months.

What I was doing at the time was synthesizing a unique landscape texture with
lighting baked in, and then load it at runtime. Then all I had to do was
specify the right texture coordinates for the terrain, instead of slowing
down the frame rate with real-time multi-texturing.

But I think this is only good for small terrain, 1024x1024 and smaller.
I would definitely go with Dreamer's suggestion and use real-time Ecosystems
like LDA does.