Swapping out Vertex Buffer Necessary for Terrain LOD?

Question

I am using Directx 11 to try and implement terrain level-of-detail.

I am trying the idea represented in this tutorial: http://www.rastertek.com/tertut18.html

Which is split your terrain into nodes, and render different quality nodes depending on how far away they are from you.

Each of my nodes has its own vertex buffer (bad idea?), however I am trying to map/unmap when I swap out a particular node for its higher quality version. I noticed that unless my vertex buffer is the size of the high quality version, then surrounding nodes gets affected, I believe this is to be expected since I am essentially overwriting memory in the vertex buffers of the other nodes. So is the only way to go about map/umap is to make each node have the space for the high quality terrain?

If so, then I can't do map/unmap because I run out of memory. What's another approach then? Making a new vertex buffer with the desired size whenever I swap? Won't this be too slow?

Answer 1

OK, I will address one specific point of our concern about swapping.

Firstly, you may consider that the vertex buffer itself may contain the highest detail version of the terrain. And that each LOD has its own list of indices that state which vertices are used in that LOD. BUT, in DirectX 11, using the DrawIndexed also allows for you to offset the indices. What does this mean? Well you can pack all your LODs into the same index buffer, and select them by just knowing that:

A) start index of the Indice B) length of the index list you want to render.

https://docs.microsoft.com/en-us/windows/desktop/api/d3d11/nf-d3d11-id3d11devicecontext-drawindexed

This also works as a strategy for Vertex buffers also, you can have all the LOD vertex information in there. SO you could represent multiple LODs easily in the same buffer.

You can also pack all your vertex buffers and indicies into singular mega buffers if you want. But you are then limited on the size of the world which may not be an issue depending on your game.

Having used rastertek, there is some thought behind why each section has its own vertex and index buffer. The main reason being that if you are dealing with larger worlds, then you need to load these in the background process. As its a grid, its easy to understand which resources should be prioritised and as such loaded. The additional calls are not such a large overhead as they are queued, you do get some level of scale from Command queues, which can shrink the impact of multiple buffers. It's a trade off. It's whether you want to swap lots of small buffers, or just large ones.

The trick is, not to continually map/unmap, but line up your buffers in the most ordered way so your calls (on the CPU side), can determine decisions such as LOD.

Hope this is a start for you.