I have finally decided upon an LOD method. It's a gpu variation of Chunked LODs. The chunk simplification is the one from geomipmapping and the height data is sampled in the vertex shader. I think it's simple and allows texture splatting unlike geoclipmaps.
Now here's where i'm stuck. For large terrains, i can't upload the entire heightmap to the gpu. Same goes for the normal map and alpha map for texture splatting. The obvious solution is to split up the textures so that each chunk has it's own set of textures.
1) I am concerned about the efficiency of this method. Because it means uploading 3 64x64 textures per chunk (heightmap, normalmap, alphamap). Then there is also the actual texture splats.
2) Editing the terrain becomes a real problem. Originally i was planning to edit the terrain by simply rendering a quad representing the brush to the textures themselves. If i split the maps, this won't work.
I would really appreciate your input on this.
Terrain woes?
Why not only render the chunks closest to the player (camera) with high detail. Less draw calls, easier to edit, faster etc...
I'm working on much the same thing. You need to abstract out your database into a quadtree database, and query the quadtree on each camera move. The database should be a set of resource (tile, heightmap etc) names (not the actual resources) which you then load from your content manager or resource manager. Performance of loading the textures into GPU isn't really a problem (or at least, its an irreducible one - they all have to be loaded at some point) but the content manager could potentially cache them based on least-used and unload those that have been loaded but have not been used for some time.
I get 20ms render time on a 50x50 set of 128x128 tiles, which all share the same geometry but are offset in the vertex shader with heightmap sampling in the vertex shader - so I'm not currently hitting any performance issues.
I get 20ms render time on a 50x50 set of 128x128 tiles, which all share the same geometry but are offset in the vertex shader with heightmap sampling in the vertex shader - so I'm not currently hitting any performance issues.
Author
Why not only render the chunks closest to the player (camera) with high detail. Less draw calls, easier to edit, faster etc...
I would like to be able to view the terrain as players would while editing.
I'm working on much the same thing. You need to abstract out your database into a quadtree database, and query the quadtree on each camera move. The database should be a set of resource (tile, heightmap etc) names (not the actual resources) which you then load from your content manager or resource manager. Performance of loading the textures into GPU isn't really a problem (or at least, its an irreducible one - they all have to be loaded at some point) but the content manager could potentially cache them based on least-used and unload those that have been loaded but have not been used for some time.
I get 20ms render time on a 50x50 set of 128x128 tiles, which all share the same geometry but are offset in the vertex shader with heightmap sampling in the vertex shader - so I'm not currently hitting any performance issues.
What about the editing?
I'm using a cell based approach, where every cell is the same size. My scale is one metre to one unit, with 128x64 cells, and each cell is 96x96 metres. This makes my world about 6.1x12.3km (75.5km2). Using 256x256 cells would give a size of 630km2 - I haven't simply because in my opinion it would be far too big to traverse.
In terms of LOD, I'm going from 0.5m up close to 16m quads furthest away (each quad is obviously divided into two triangles), and using indexed triangle strips to extract height from a height map. I only need a height map of 385x769 to describe the entire world at the lowest resolution, and I page in the higher res areas only where I need them.
The LOD is based on concentric rings around the player, with only a few of the highest LODs in use at any one time. One obvious problem with such a system is LOD geometry popping. I'm overcoming this by creating the entire world at the 16m level - all other LODs simply refine the basic shape with detail, but add nothing fundamental to the terrain. This nicely solves that problem.
I'm also going to use a PVS, where I keep a record of all potentially visible cells from the cell I’m in, and cull them against the frustum at render time. This massively reduces the CPU side processing.
This still leaves a potentially huge number of cells to render, So I'm being careful, and deliberately placing large-scale vis blockers (mountains) where necessary.
Incidentally, I’ve chosen 96x96m cells because it can be made very cache friendly for both [nominally] 16 and 32 post transform cache entries.
By extending the number or size of cells, you could easily implement the same approach, which is extremely easy to do, without any fancy on-the-fly LOD algorithms.
In terms of LOD, I'm going from 0.5m up close to 16m quads furthest away (each quad is obviously divided into two triangles), and using indexed triangle strips to extract height from a height map. I only need a height map of 385x769 to describe the entire world at the lowest resolution, and I page in the higher res areas only where I need them.
The LOD is based on concentric rings around the player, with only a few of the highest LODs in use at any one time. One obvious problem with such a system is LOD geometry popping. I'm overcoming this by creating the entire world at the 16m level - all other LODs simply refine the basic shape with detail, but add nothing fundamental to the terrain. This nicely solves that problem.
I'm also going to use a PVS, where I keep a record of all potentially visible cells from the cell I’m in, and cull them against the frustum at render time. This massively reduces the CPU side processing.
This still leaves a potentially huge number of cells to render, So I'm being careful, and deliberately placing large-scale vis blockers (mountains) where necessary.
Incidentally, I’ve chosen 96x96m cells because it can be made very cache friendly for both [nominally] 16 and 32 post transform cache entries.
By extending the number or size of cells, you could easily implement the same approach, which is extremely easy to do, without any fancy on-the-fly LOD algorithms.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
