Jump to content
  • Advertisement
Sign in to follow this  
Florian22222

LOD Heightfield

This topic is 2504 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 :D

Share this post


Link to post
Share on other sites
Advertisement
2048*2048*36=144MiB hardly a problem.
Modern games rely on depth shadow buffers, a popular tech is parallel split shadow maps, you'll use up to 4096² for the depth shadow buffer, for 4 2048² splits, that's only 64MiB.
(That's only for high-end cards, you'd reduce the number of split an the depth shadow buffer resolution to scale on slower hardware. Try starting with 2 1024² splits to begin with.)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

´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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!