I'm currently creating multiple terrain cells, each one having it's own vertex buffer. When I need to draw one of them I set it's vertex buffer on the pipeline, and the relative index buffer. But I've recently implemented level of detail on my terrain and I've been having some issues, one of them is having cracks between terrain cells with different LOD. After thinking, I've been considering using just one large vertex buffer for my entire terrain, and using multiple index buffers to only render specific cells during runtime, and them having the same cell with more than one index buffer representing different LODs. This would be a huge change on architecture of terrain generation, but it might be worth even though I'm not sure. If someone could guide me over this it would help me very much, and feel free to give other ideas.

The problems you describe don't really have anything to do with the representation of the buffers, but instead with the model data itself.

It is not something done automatically, but it's a problem that has been solved for decades. If you have an IEEE subscription yourself or through school, one of many papers on it here. I know the author of the paper, he used to have it free on his web site, now I'm only finding it through IEEE, but you may have better luck on the search for it or for papers it cites.

To avoid cracking basically you need to divide the terrain in a way that avoids T-junctions. It is trivially easy with a regular grid, just don't put T's in there. If your mesh is irregular it can be a bit of computation work, but it isn't particularly difficult.

To avoid popping on LOD changes you need to do some computation work to morph between the two models. First generate the model that matches your lower level LOD on vertex positions but has higher resolution, then morph/lerp/animate the final destination points. When moving backwards to the opposite, morph/lerp/animate from the high res to the low res positions, then swap models.

@frob Ok, thank you, so if it's just all about algorithms then I think I just need to take some time to read more and fix this so my terrain can look smooth ?

RafaelFe18 said:

After thinking, I've been considering using just one large vertex buffer for my entire terrain, and using multiple index buffers to only render specific cells during runtime, and them having the same cell with more than one index buffer representing different LODs. This would be a huge change on architecture of terrain generation, but it might be worth even though I'm not sure. If someone could guide me over this it would help me very much, and feel free to give other ideas.

You can use common large IndexBuffer with offsets for representing different LODs.

RafaelFe18 said:
one of them is having cracks between terrain cells with different LOD

1. You need additional triangles to avoid cracks between cell with different LODS - It can be implemented using different indices inside common large IndexBuffer(see my explanation above)
2. Vertex Morphing (see frob post)
3. Use Hardware Tessellation! You needn't create additional Indices and Switch LOD on CPU or morph Vertices on VertexShader. Hardware Tessellation this is the best choice. You need to create a small VertexBuffer with 4 Vertices per patch and fetch Vertices from a HeightMap's texture Inside a Domain Shader. It will improve performance and decrease a Memory's Usage.

With HW tessellation you can only subdivide 64x. So if your 4-vertex patch is too big, you won't be able to get enough detail. Consider if that's enough for your terrain application.

Consider using regular grid vertex morphing where on a closer (nicer) tile you morph its vertices towards the farther (2x uglier) tile, collapsing into the uglier vertices. Look up CDLOD, it isn't too difficult to implement yourself.

Also consider not having a vertex buffer at all (just an index buffer). It is very easy to synthesise all vertex data solely from the vertex index (SV_VertexID) in VS.