This is a short summary of a new terrain rendering implementation I worked on, which was halted when it was discovered Unity Technologies were implementing this exact feature-set in their latest version of Unity.
In an attempt to bring down the rendering costs of a large, detailed terrain, I worked on implementing rendering the terrain as a number of GPU-instanced tiles, reading from a global heightmap to set height, splat, normals and tint.
The tiles were scaled to fit a quadtree, which was continuously reconstructed based on the camera position, giving something like this:
This gives a decrease in detail level to a power of 2 over distance, yielding a good result from a 1st person camera view
The tiles sample from initially instantiated world position in a page texture, where each channel represents offset in U, offset in V and LOD-level for sampling scale.
The sampled LOD level is then used to reposition the vertex in the XZ-plane. This is done as each tile is scaled ever so slightly to have the edge vertices sample from the neighbour tile LOD level. This thereby snaps the edges onto lower LODs, avoiding gaps.
The before-mentioned UV coordinates in the page texture serve a different purpose.
To avoid a massive consumption of VRAM for 8k or 16k height-, normal-, splatmap-, tint- and other maps, a technique is used called Clipmapping.
Clipmapping is the predecessor to Virtual Textures and works by only uploading areas of the textures needed, at the LOD-levels needed, basedon distance from the camera.
To avoid overly complex sorting and partitioning, this system uploaded cells of the same size every time, giving even spacing in the texture holding the currently used data (“Physical Texture”), instead resolution was adjusted by having the same 128 or 256 pixel cell cover a tile of 50, 100, 200, 400 or 800 units.
Another reason for this design was to make all terrain-data available GPU-side, so shaders could sample the needed information to blend seamlessly into the terrain, as here demonstrated with crater models.