How to incorporate vertex texture fetch with terrain block for large terrain rendering? I am a beginner for terrain rendering. I have used one 1024*1024 size heightmap as a whole vertex texture to render terrain. But I have no way to realizie view frusrom culling. Now I want to render a larger terrain, such as 4096*4096 or even larger such as 16384*16384. So I want to use the terrain block method.The question is how to incorporate vertex texture fetch with terrain block for large terrain rendering. Does the whole heightmap for fetch need to be also patched? How to use VTF on each terrain block individually? Any suggestion would be appreciated.Thanks a lot.

if you create just 1 block of vertices and indices with the size of, say, 128 * 128 and you virtually keep track of all boundingboxes where this block could be. you chunk the large heightmap into small tiles. You can then render the blocks to the GPU multiple times depending on which bounding box is visible in your view frustum. Each bounding box carries the associated heightmap so that when you render a block, you render the heightmap along.

though this does not give you the possibility to render enormous large terrains (with full visibility) and you will need a buffering system to load in tiles as you move over the terrain, since your video memory is ismply not big enough to load in 16000^2

take a look at for example terrain geometry clipmaps

Thanks FeverGames!
I am very appreciated for your reply.

Now I only want to realize view frustrum culling in 1024*1024 size height map using VTF.

Suppose the block is 128*128

Quote:if you create just 1 block of vertices and indices with the size of, say, 128 * 128

Quote:You can then render the blocks to the GPU multiple times depending on which bounding box is visible in your view frustum.

Do you mean that I first use a block ,size,128*128, contains no height?Then translate the block in the vertex shader?

how to chunk the 1024*1024 heightmap into small tiles. Is there any tools or method to do this? can you tell me more detail about this?

Is there any related links or tutor,or paper for my trouble.

well a heightmap can be chunked up by reading and writing the texture data, what language are you writing your code in?

the block of 128x128 is indeed transformed on the GPU by the vertex shader. Do mind that this requires shader model 3, cause vertex texture fetch is not supported in older shaders.

if you want to transform the data not realtime on the gpu, you can create (1024/128)^2 tiles of data and transform them on the cpu. On these blocks you do simple view frustum culling to avoid rendering data outside of the frustum.

I have no concrete document explaining this, but i have one about geometry clipmaps, but that's a more advanced topic..

Thanks FeverGames!

Quote:what language are you writing your code in?

I am writing code in opengl, GLSL V1.2,and I use Geforce 9500 card.

Quote:if you want to transform the data not realtime on the gpu, you can create (1024/128)^2 tiles of data and transform them on the cpu

I want do frustum in GPU, not on CPU. Is it possible?

Can you provide some code ?

Tanks a lot

i don't think tht is possible, because of the simple fact that when its send to the gpu it gets processed. Frustum culling is meant to be sure that parts that need not to be rendered get skipped BEFORE the render to card pass

If you want culling (and believe me, you want it when you use terrains ;) ) the simplest way to do it would be with quadtrees.

For the basics of a quadtree you can look at this link:
Link

Let's assume your max size is 16k*16k and you want your smalles chunk to be 64*64.
You'd need a quadtree with a depth size of 8 or in other words, quarter the quadtree 8 times. With this you have a nice seperation of your terrain and it only consists of small chunks.

Culling with a quadtree is pretty easy and there are many tutorials out there where this is described more in depth. The cool thing about quadtree and culling is that you'll only draw the chunks which the player is seeing. The smaller the chunk size the more precise but you'll get more draw calls through it!

Now you do the height fetching on the GPU so you only need to send a 64*64 grid to the GPU for every chunk.

With this way it would work very robust on ground level. When you want to fly around things can get pretty intense. No LOD and many draw calls will soon make you fillrate limited on GPU side. But you can play around with the chunk size(make them 128 or 256) which will result in a better performance but LOD would still be missing.

But if you have come so far it's easy for you to implement geomipmapping cause you have everything else setup. ;)

You obviously want to send only the (partially or fully) visible blocks to the GPU using frustum culling on the CPU.

But if you use a large block size, you might be interested in also branching in the vertex shader before you do the heightmap lookup (to avoid the VTF that is relatively expensive on older GPUs). There's an idea for that in the section "Avoiding unnecessary Work with Branching" in the article "Using Vertex Texture Displacement for Realistic Water Rendering" from GPU Gems 2 (http://developer.nvidia.com/object/gpu_gems_2_home.html). Note the author points out the mesh has to be finely tessellated to avoid most clipping issues. Finding suitable (fudge) constants probably requires some experimentation...

Quote:
Now you do the height fetching on the GPU so you only need to send a 64*64 grid to the GPU for every chunk.

method 1: only draw one 64*64 grid ,then translate overall in vertex shader

method 2: noramlly draw the whole gride ,each block has 64*64

Is there differ between the two method?

Maybe I should try .I need use my hand to find.

Tanks

For VS texture terrains, the camera can be in a corner of the 'grid' which isnt a regular grid, but a cone shaped to the frustum. This makes frustum occlusion unnecessary. Obviously verts are spaced more further away to give some LOD.

To merge multiple heightmaps, you can simply render the maps into a single texture in a background thread, you only need to do it when you move a certain distance, so it's not a big concern. You can merge normal maps the same way to save having to calculate them. A precalculated shadow texture or any other map of the sort could also be used.

This technique also supports maintaining a separate heightmap for diggable terrain (puts old school voxel/marching cube techniques to shame). Also, rather than having a terrain heightmap, you can tile multiple noise maps and generate terrain based on that info. This technique is very good for that, massive pseudo-random terrains.

To give better detail for the distant mountains, you can gravitate the verts towards points of interest like mountain tops. How you implement that is a little involved, and I haven't solved this 100%, but am happy with results so far.

Keep in mind not all VS 3.0 compatible cards can do VS texture sampling, so this technique may not be attractive for the more commercially oriented. That aside, I personally find it very exciting; a massive pseudo-random terrain, which is diggable, I havent seen any commercial game like it.