There is an inherent flaw with the algorithm used for generating dynamic levels of detail in height-map generated landscapes.  Polygon edges of a higher-level of detail patch do not line up with the same point midway on a lower level of detail patch, creating cracks between triangles along the terrain.  "Stitching" is required to fill in the cracks.  When I started the landscape algorithm, I did not initially support dynamic level of detail--I just wanted something easy that could render tens of thousands of triangles at a time.  That changed when I implemented vertex blending and needed something to test it on.  I made some assumptions that turned out to be false in my initial design and therefore the problem cannot be fixed in a graceful manner.  A new implementation is required.

The current implementation leverages the software renderer's intrinsic ability to render 4 triangles at a time.  The granularity of patch subdivision is 4x4 (4 strips of 4 quads, or 8 triangles) for each level of detail.  The level of detail is based on how distant the camera is from the center of the patch, or more accurately, the computed surface area of the triangles at the center of the patch when projected into screen space.  When the lod threshold is exceeded as the projected triangles grow too large, the patch is subdivided and new triangles are generated at a higher level of detail until the highest level is achieved.  As the camera moves forward, each patch is "blended" from a lower resolution mesh towards a higher resolution mesh.  As the blending occurs, polygon edges separate from adjacent triangles of a lower level of detail.  If I disable vertex blending but maintain dynamic level-of-detail, the cracks disappear.  This is because the vertices on the edge at the higher lod patches are property positioned in regards to their lower lod neighbors, but as the vertices blend to the next level of detail they begin to pull away and the cracks appear.

At first, the solution seemed relatively simple (in theory); I would just need to put some stitch points in the lower lod patch.  But in practice, there isn't anyway to blend the vertices individually, which means the stitch points will still come apart.  Not only that, but different sides of the patch could have different levels of detail, and that makes it difficult (and slow) to figure out the correct stitch points anyway.

In the end, it turned out to be a flawed algorithm.  The bandaid is to make the patches overlap--create patches that are still 4x4 but space them as though they were 3x3.  In doing this, the cracks disappear and the z-buffer resolves the ordering issues.  But in the software rasterizer, the ammount of overdraw is brutal and slows things quite considerably, but it should work in hardware just fine ;)