Hello!

For a game I am creating i need a open world terrain. I create it from a texture. The size will be about 1-2k x 1-2k. As you see a really big area. Without LOD this isnt affordable on a middle-ware laptop like mine.

So I´ve red a little bit about LOD. Should i use quadtrees with one big index buffer? Furthermore if i use a terrain out of 2kx2k vertices there wil be 4000000 vertices. each vertex has a size of 36 bytes. That means 1,4gb for the lowest lod.

So I thought of using chunks that are loaded in time. But isn´t it a problem when looking from a mountain into a really big plain that the world just ends?

Another problem are the shadows(wih lightmaps). I think this all costs so much memory. Isn´t there an efficient way to handle this?

Can I get this working or should i just design my game into regions?

I hope you can help me a little bit with this problem

Hmm maybe i just should make smaller areas..Sry I accidentally added a 0 to 140mb^^.
So i want to split my terrain into quadnodes. How do i define the quadnodes?

I thought of something like this:

struct QuadNode
{
int LOD;
int startIndex;
int indexSize;
}


I´ll be using 1 indexbuffer and fill it with all indices ever used on the terrain, but only draw the one that I need(refering to LOD)

Furthermore if I need bigger areas I´ll use chunks that I load from the hard disk.

Is this a valueable approach?

can you use a smaller datatype for each vertice? if your world is only going to be 2k by 2k at max, you may be able to get away using shorts instead of what you're using now.

No that cant be the solution. Short = 16bit = 2^16 possibilities = 65536
but on a 2k x 2k field i have 4000000

Hi,

You don't need to store every single terrain vertex in the memory in the same time.

Your quad tree nodes could/should have fixed size grid for vertices, let's say 33x33 vertices. With a proper transformation matrix, you can scale this one mesh to fit to all the node sizes. Now, we got already 12 bytes out of your vertex structure. That's 1/3 of the space already. When drawing, you can read the z-values from a height texture. Also you can read a normal from a texture too. Now we got another 12 bytes away from the vertex size. Again save of 1/3 from the vertex data. Now what we have left ... texture coordinates? You may generate them from the world position if it suits for your needs. Ok, now your vertex structure for individual vertices has size of 0. For the grid (which you could also generate on the GPU actually) you need some x and y coordinates which you could store in 1 dword.

Now only thing is to provide a good height and normal texture for the mesh rendering. Even the normal could be calculated in the shader from the height map.

Cheers!

There are very easy ways to render large terrains:
http://skytiger.wordpress.com/2010/11/28/xna-large-terrain/

There are very easy ways to render large terrains:
http://skytiger.word...-large-terrain/

I´ve red a little bit in it and it´s very interesting and helpful, but I have a few questions.
First: Isn´t it to performance-intensive to tesselate the vertices each frame according to the players position?
The second one is: How does the algorithm handle the new vertices created in the tesselation? It should be working with dx9(no geometry shader). Does the algorithm transfer the vertices created on the cpu to the gpu every frame?

´ve red a little bit in it and it´s very interesting and helpful, but I have a few questions.
First: Isn´t it to performance-intensive to tesselate the vertices each frame according to the players position?
The second one is: How does the algorithm handle the new vertices created in the tesselation? It should be working with dx9(no geometry shader). Does the algorithm transfer the vertices created on the cpu to the gpu every frame?

The terrain mesh is static.
All I do is position and rotate it to cover all the terrain the camera can see - and then modulate its height with VTF.
If the camera is looking to the right - I position the static mesh to the right ...
The whole point in my technique is "large scale terrain is easy" you don't have to DO anything per frame except adjust a couple of effect parameters and call draw a few times.
IMO All this quadtree, clipmap and roam stuff is totally unnecessary academic madness.

I added this to my blog to make it clearer:

Quick Recipe

• At startup create or load two triangle shaped planar meshes (pizza slices)
  
• Each frame position and orient these meshes to cover the terrain area visible in the view frustum
  
• In the vertex shader transform world-space positions into texture-space, sample the height map using VTF (Vertex Texture Fetch) and displace the height of the mesh
  
• Use Catmull-Rom interpolation to determine the heights of mesh vertices that lay between height texels
  
• Use Uniform Basis Spline interpolation to create perfectly smooth normals
  

You have a simple and efficient large scale terrain renderer which uses almost no CPU, no CPU-to-GPU bandwidth, and is very GPU friendly! There is no need for quadtrees, octrees, clipmaps, roam or dynamic mesh generation.

Hmm seems really well.
I´ll add a chunk-technique to it for real big terrains(i want to make a seamless big world)

Thank you!