I have read the paper <GPU Terrain Rendering> in game programming gems 6. The method is using one small VBO ,resuse it over and over again to render a large terrain. I can use 33x33 vertex buffer to render the whole terrain by vertex texture fetch ,using one 2049*2049 sized heightmap texture. My question is how to get rid of the limitation of only using one heightmap texture. How to use several heightmap textures to do VTF? Is the texture array extension in SM4.0 a corret method to resolve it? The following description is what I would use for large terrain rendering. I plan to split one 8192*8192 sized heightmap into 8*8 heightmaps using L3DT software, so each has 1024*1024 size. I plan to use the texture array extension to load each 1024*1024 block as a layer for the whole 8192*8192 terrain. I am not sure I am correct. Is there any paper which describe the combination of VTF and texture array in large terrain rendering.

Well, you could do exactly the same algorithm without using texture arrays. Just set the heightmap to a different texture before you render an individuals block. Texture arrays (or even the big heightmap texture) would be an optimization, so you can use batching/instancing on all your small blocks.

thank harveypekar!

[/q]
just set the heightmap to a different texture before you render an individuals block.
[/q]

I will try.


[/q]
Texture arrays (or even the big heightmap texture) would be an optimization, so you can use batching/instancing on all your small blocks.
[/q]

I am not very clear your description about texture array .

I found a paper "Real-time Rendering and Manipulation of Large Terrains 2009_12.pdf" published by IEEE. In this paper ,the author use texture array for terrain rendering

Before worrying about how the textures are represented by the GPU, consider these questions:

- Are you trying to render all of the terrain?

Do you want to have distant terrain fade away, or use a backdrop instead of a grid etc. Most games will use a variety of techniques to avoid rendering the entire world. There are fancy techniques to occlude terrain (eg make terrain hilly and pre-calculate or do occlusion rendering to determine which grids are visible from which camera positions).

- Are you trying to render the terrain with a constant level of detail?

You may want to draw bigger triangles if they are further away. This will affect the grids design. You may want to just have one big grid, which has increasingly larger triangles further away from the camera. Alternatively, you could have several LOD grids, or even scale the grid, but this could be tricky stitching edges of different sized neighbors.

- Do you want to frustum cull at all?

You can do this by either testing if a grid is in view and not rendering it, or having a single grid, which is really a wedge and it is rotated so the camera always sees it.

- Do you know how to write a thread that can load and unload textures in the background as the camera moves around?

A background thread can load multiple height maps and render them all to a single height map that you use for the VTF. This assumes you don't want to draw the entire world at once.

- Do you think you'll want to use normal maps, light maps or texture maps for the terrain?

These are additional textures that would be handled the same way as the height map. This can have some influence on how you render the height map. For example, to get a normal for a point at the edge of a height map, you will need to sample the neighbouring height map.

You can use up to 4 different samplers in the vertex shader under vs 3.0 so I dont see the problem.

This is an interesting thread.

Quote:Well, you could do exactly the same algorithm without using texture arrays. Just set the heightmap to a different texture before you render an individuals block. Texture arrays (or even the big heightmap texture) would be an optimization, so you can use batching/instancing on all your small blocks.

In my chunked LOD terrain, i have one 33x33 patch (xz only) which is used to represent all terrain chunks - I translate it and scale it depending on its position within the entire terrain. In the vertex shader, I then look up the y value from the terrain vertex texture.

Can I apply hardware instancing to this? So the first vertex stream contains the 33x33 patch and the second one contains the translation and scale matrices. Does this mean I could draw the entire terrain (i.e. all the chunks required) in one draw call?