Generally, I think power-of-two is not such an awesome choice, power-of-two-plus-1 is better. This allows you to do LOD much more easily. A grid of 257*257 vertices very nicely splits into two grids 129*129 vertices each, with one vertex shared at the edge. You want to share the vertices at the edge, or you must do extra work to avoid "holes".
If you make the chunks smaller, the time to compute them and the memory requirement will decrease quadratically. For example, 64*64 only takes 1/16 the memory (and time) compared to your choice of 256*256. Of course when chunks are smaller, you will need a larger number of them, but you have a better granularity.
As already stated in your other thread, you will want to have a "cache". You will need the surrounding 9 tiles in any case, but it is better to start off with e.g. 25 (the surrounding 5x5 instead of 3x3). If you make them 64*64, those 25 tiles will alltogether take less memory than 2 tiles at 256*256. Now don't be too cheap and make your cache capacity somewhat bigger, say, 50 or 100 tiles (decide at program start based on how much memory you have). This will save you from re-computing (or loading from disk, whatever) the same data again and again if the player moves around in a "typical" pattern.
You don't know where the player will move, but no matter where, if you start out with 25 tiles, another one is always immediately available, no matter which direction the player moves. This is nice.
As the player moves, precompute new tiles in the direction the player moves, and add them to the cache. If you are comfortable with threading and synchronization, you can push this work to one or several background threads.
The cache will eventually become full and evict the least fit tile (oldest, farthest away, or some combination, or some other metric) to make room for another one.
Note that everything greatly depends on your requirements. I cannot exactly tell you what resolution your tiles must be, what chunk size they need to be, or how many you need to precompute. For example, assuming 64 meters per tile on 1m/vertex and 0.1s to compute a new tile, a player moving at 230 km/h could outrun your computations. If the player avatar is a sports car, this may be a problem, and you definitively need a bigger set of tiles and/or faster computations. If the avatar is a human, it's not going to happen. You may need more or fewer vertices, depending on what you want and on what you can deliver computation-wise.
Tiles that are more than 1-2 tiles away can eventually be a lower LOD. Again, the exact details depend on your requirements, I cannot give you a precise figure. An ant, a dwarven fighter, an airplane, and a starship have different horizons, and a grid resolution of 1km is not the same as a grid resolution of 1mm.
If (assuming a "kind of normal" setting) you have a 1 meter distance between vertices, the second closest tile will on the average be 96 meters away. It is usually acceptable (and even desirable!) to draw things that far away with less detail. On the other hand, if you have e.g. 16 vertices per meter, then we're only talking about 6 meters. You probably don't want to reduce detail at such a close range.
You probably want to have the higher levels of detail in a cache too, but the lower the level of detail gets, the more you can just as well calculate terrain on the fly. Three levels lower, you only have 81 vertices total (9x9) in a patch.
Show differencesHistory of post edits
#1samoth
Posted 22 June 2012 - 05:57 AM
Generally, I think power-of-two is not such an awesome choice, power-of-two-plus-1 is better. This allows you to do LOD much more easily. A grid of 257*257 vertices very nicely splits into two grids 129*129 vertices each, with one vertex shared at the edge. You want to share the vertices at the edge, or you must do extra work to avoid "holes".
If you make the chunks smaller, the time to compute them and the memory requirement will decrease quadratically. For example, 64*64 only takes 1/16 the memory (and time) compared to your choice of 256*256. Of course when chunks are smaller, you will need a larger number of them, but you have a better granularity.
As already stated in your other thread, you will want to have a "cache". You will need the surrounding 9 tiles in any case, but it is better to start off with e.g. 25 (the surrounding 5x5 instead of 3x3). If you make them 64*64, those 25 tiles will alltogether take less memory than 2 tiles at 256*256. Now don't be too cheap and make your cache capacity somewhat bigger, say, 50 or 100 tiles (decide at program start based on how much memory you have). This will save you from re-computing (or loading from disk, whatever) the same data again and again if the player moves around in a "typical" pattern.
You don't know where the player will move, but no matter where, if you start out with 25 tiles, another one is always immediately available, no matter which direction the player moves. This is nice.
As the player moves, precompute new tiles in the direction the player moves, and add them to the cache. If you are comfortable with threading and synchronization, you can push this work to one or several background threads.
The cache will eventually become full and evict the least fit tile (oldest, farthest away, or some combination, or some other metric) to make room for another one.
Note that everything greatly depends on your requirements. I cannot exactly tell you what resolution your tiles must be, what chunk size they need to be, or how many you need to precompute. For example, assuming 64 meters per tile on 1m/vertex and 0.1s to compute a new tile, a player moving at 230 km/h could outrun your computations. If the player avatar is a sports car, this may be a problem, and you definitively need a bigger set of tiles. If the avatar is a human, it's not going to happen. You may need more or fewer vertices, depending on what you want and on what you can deliver computation-wise.
Tiles that are more than 1-2 tiles away can eventually be a lower LOD. Again, the exact details depend on your requirements, I cannot give you a precise figure. An ant, a dwarven fighter, an airplane, and a starship have different horizons, and a grid resolution of 1km is not the same as a grid resolution of 1mm.
If (assuming a "kind of normal" setting) you have a 1 meter distance between vertices, the second closest tile will on the average be 96 meters away. It is usually acceptable (and even desirable!) to draw things that far away with less detail. On the other hand, if you have e.g. 16 vertices per meter, then we're only talking about 6 meters. You probably don't want to reduce detail at such a close range.
You probably want to have the higher levels of detail in a cache too, but the lower the level of detail gets, the more you can just as well calculate terrain on the fly. Three levels lower, you only have 81 vertices total (9x9) in a patch.
If you make the chunks smaller, the time to compute them and the memory requirement will decrease quadratically. For example, 64*64 only takes 1/16 the memory (and time) compared to your choice of 256*256. Of course when chunks are smaller, you will need a larger number of them, but you have a better granularity.
As already stated in your other thread, you will want to have a "cache". You will need the surrounding 9 tiles in any case, but it is better to start off with e.g. 25 (the surrounding 5x5 instead of 3x3). If you make them 64*64, those 25 tiles will alltogether take less memory than 2 tiles at 256*256. Now don't be too cheap and make your cache capacity somewhat bigger, say, 50 or 100 tiles (decide at program start based on how much memory you have). This will save you from re-computing (or loading from disk, whatever) the same data again and again if the player moves around in a "typical" pattern.
You don't know where the player will move, but no matter where, if you start out with 25 tiles, another one is always immediately available, no matter which direction the player moves. This is nice.
As the player moves, precompute new tiles in the direction the player moves, and add them to the cache. If you are comfortable with threading and synchronization, you can push this work to one or several background threads.
The cache will eventually become full and evict the least fit tile (oldest, farthest away, or some combination, or some other metric) to make room for another one.
Note that everything greatly depends on your requirements. I cannot exactly tell you what resolution your tiles must be, what chunk size they need to be, or how many you need to precompute. For example, assuming 64 meters per tile on 1m/vertex and 0.1s to compute a new tile, a player moving at 230 km/h could outrun your computations. If the player avatar is a sports car, this may be a problem, and you definitively need a bigger set of tiles. If the avatar is a human, it's not going to happen. You may need more or fewer vertices, depending on what you want and on what you can deliver computation-wise.
Tiles that are more than 1-2 tiles away can eventually be a lower LOD. Again, the exact details depend on your requirements, I cannot give you a precise figure. An ant, a dwarven fighter, an airplane, and a starship have different horizons, and a grid resolution of 1km is not the same as a grid resolution of 1mm.
If (assuming a "kind of normal" setting) you have a 1 meter distance between vertices, the second closest tile will on the average be 96 meters away. It is usually acceptable (and even desirable!) to draw things that far away with less detail. On the other hand, if you have e.g. 16 vertices per meter, then we're only talking about 6 meters. You probably don't want to reduce detail at such a close range.
You probably want to have the higher levels of detail in a cache too, but the lower the level of detail gets, the more you can just as well calculate terrain on the fly. Three levels lower, you only have 81 vertices total (9x9) in a patch.