A node in a quad tree used to store a patch of terrain.
Algorithm overview: Our goal is to perform traditional chunked LOD with geomorphing. But, instead of just dividing the terrain into tiles, we will divide them into a hierarchy of tiles, a quadtree, where any level of the quadtree can be a rendered tile (to the exclusion of its children). The idea is to collect together children into a larger batch with their siblings as LOD decreases, to improve performance. The minBatchSize and maxBatchSize parameters on Terrain a key to defining this behaviour. Both values are expressed in vertices down one axis. maxBatchSize determines the number of tiles on one side of the terrain, which is numTiles = (terrainSize-1) / (maxBatchSize-1). This in turn determines the depth of the quad tree, which is sqrt(numTiles). The minBatchSize determines the 'floor' of how low the number of vertices can go in a tile before it has to be grouped together with its siblings to drop any lower. We also do not group a tile with its siblings unless all of them are at this minimum batch size, rather than trying to group them when they all end up on the same 'middle' LOD; this is for several reasons; firstly, tiles hitting the same 'middle' LOD is less likely and more transient if they have different levels of 'roughness', and secondly since we're sharing a vertex / index pool between all tiles, only grouping at the min level means that the number of combinations of buffer sizes for any one tile is greatly simplified, making it easier to pool data. To be more specific, any tile / quadtree node can only have log2(maxBatchSize-1) - log2(minBatchSize-1) + 1 LOD levels (and if you set them to the same value, LOD can only change by going up/down the quadtree). The numbers of vertices / indices in each of these levels is constant for the same (relative) LOD index no matter where you are in the tree, therefore buffers can potentially be reused more easily.