Terrain Distance
Hi,
I am working on a terrain rendering engine and I am wondering how those of you that worked on similar projects set the terrain distance.
When I set it to a acceptable value I need at least a field of view of 256 tiles in each direction which already sums up to 512x512 with no possible movement involved because of the edge.
With the kind of datastructure I am using for my terrain I need 12 byte (texture, heightdata, heightlod, dynamic lightning+shadows, detailmap, etc...) per tile. This would amount for a 1024x1024 map to 12megabytes of memory. This is not that much but it also doesn't leave much room for navigation.
So I wonder how you solve this kind of problem to have a huge terrain and being able to traverse it seamlessly.
Are there any established techniques to achive this ?
I'll move this over to 'Graphics Programming & Theory' for further discussion - this problem is largely API independent.
My current approach is to look into multi-threading (although I'm currently trying to cheat via ID3DX10ThreadPump's [cool]) and an in-memory working set. My previous attempts at this were reasonably successful as you can usually page in/out terrain tiles fast enough to avoid any problems with rendering (especially if you use LOD algorithms).
Geometry will rarely be a problem as you can often use matrices along with indices and offsets to re-use sections (or streams) of data. The bigger problem is almost always texture storage - getting a decent texel density on a large terrain can quite easily take up gigabytes of storage!! In this case the standard approach is to use texture compression and with the 6:1 ratio (iirc) of the BC formats is usually plenty good enough.
hth
Jack
My current approach is to look into multi-threading (although I'm currently trying to cheat via ID3DX10ThreadPump's [cool]) and an in-memory working set. My previous attempts at this were reasonably successful as you can usually page in/out terrain tiles fast enough to avoid any problems with rendering (especially if you use LOD algorithms).
Geometry will rarely be a problem as you can often use matrices along with indices and offsets to re-use sections (or streams) of data. The bigger problem is almost always texture storage - getting a decent texel density on a large terrain can quite easily take up gigabytes of storage!! In this case the standard approach is to use texture compression and with the 6:1 ratio (iirc) of the BC formats is usually plenty good enough.
hth
Jack
Ah sorry, I am hanging out so much in the DX section that I totally overlooked that this is not DX related.
And well, I seem to have the problem with the geometry instead of the texture.
I am using various detailmaps close up so it doesn't matter that the basemap is low quality because its far away anyway with barely any discernible features to it.
The problem is that I cannot reuse any kind of geometry (due to realtime changes) so I think splitting it in chunks and only having the necessary geometry online and paging the rest in and out (maybe even with a more detailed basemap) might be the way to go.
Is an extra thread to handle this ok or would using another core for it better ?
Is there maybe a completely different way to go about this ?
And well, I seem to have the problem with the geometry instead of the texture.
I am using various detailmaps close up so it doesn't matter that the basemap is low quality because its far away anyway with barely any discernible features to it.
The problem is that I cannot reuse any kind of geometry (due to realtime changes) so I think splitting it in chunks and only having the necessary geometry online and paging the rest in and out (maybe even with a more detailed basemap) might be the way to go.
Is an extra thread to handle this ok or would using another core for it better ?
Is there maybe a completely different way to go about this ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement