My approach is that each patch stores an array of its 4 neighbours.
To calculate lods, I iterate through all the patches, and determine the lod based on the distance of the camera from the patch's AABB. By using that simple approach and tuning the lod thresholds, I find I can avoid having situations where the lod changes by more than one. Once each patch has decided on its own Lod, I can iterate through them all again and decide on the index buffer to use that will eliminate cracks (using the BTT algorithm I posted earlier in the thread).
The tricky bit is actually generating the list of neighbours in the first place. My game is a tile based strategy game, and I actually have a hierarchy of classes that make up the structure:
- Face (one of the 6 faces of the cube)
- Section (often I can't stretch a single texture across a whole face, or there's too many vertices for a vertex buffer, so I split a face into sections, I can render patches within a section with no render state changes)
- Patch (the unit of lodding)
- Cell (the game based tile)
For my strategy game, the cells need to know their neighbours anyway for gameplay reasons, so to calculate the patch's neighbours, I'm just peeking at their cell's neighbours.
My code that calculates cell's neighbours is particularly inelegant (not least because my cells need to know diagonal neighbours too), so I don't think I'll be able to post anything helpful. The approach is that I have a function that will stitch one edge of the rectangular grid of cells that make up a face to another edge of a grid of cells and I call that 12 times for the 12 edges of a cube to build up the neighbour lists. Because of the topology of a cube, some of the stitches require a reversal of the direction.