I think I got it now. You have a facinating system. I'm trying to re-implement a similar scheme on my end.

Currently I'm generating color textures, terrain vertexes, lightmap, & heightfield in each QuadTree node. I definitly see why you split the two, I'll have to do the same soon.

I'm curious as to how you pick the color texture to use if the two trees are not in alignment? Do you just climb back up the tree until you find a node that has a color texture attached?

So when you split a node, the 66x66 heightmap is generated, then the 64x64 lightmap and the vertex grid from it. Is your lightmap a simple shading scheme using vertex normals at each heightmap location or did you devise something different?

Now it's rendering time and you are at a QuadTree node that needs to be rendered (so the heightfield and lightmap are readily available). Where do you get the 64x64 color texture that is streched over it? How do you decide if a new color texture needs to be generated or if a parent node's texture is good enough?

BTW: There's a paper that describes a possible solution for this problem (http://www.bolt-action.com/dl_papers.html).

As for the actual generation of the color textures, it appears that you have two palettes, one for sand and one for mountains. It appears to select these based on the slope of the landscape at that point. Is this what you are doing?

Make sure you post some screens of the new system! I'm sure they'll be truely sweet to behold. And thanks for the continued discussion.

I don't really use a lightmap, the texture is the final illumination, but conceptually, my lighting is just your standard diffuse dot product sampled from a height map. I take the cross product and normalize to find the surface normal from the height map at each texel(performing a square root), do the dot product, and then multiply this illumination by the color texel evaluated at that same point. To conserve memory, I actually don't store the 66x66 height and color fractals, so part of this loop involves generating both of them as well. I have a way of doing all this junk fairly quickly.

On an Athlon 600, it is taking about 1 millisecond to generate the final 64x64 texture which is pretty darn good. (thats like 150 clocks per texel) I am guessing that something funny is going on - either microsoft has implemented 3DNow optimization in msdev, or the Athlon is just a funny and very fast chip. On a P3 600, it takes about 3.5 milliseconds to generate the same texture. Thats about 500 clock cycles per texel, which is unfortunately quite slow.

This is a frame-coherent LOD, so decisions to generate new textures or new grids are always implicit in the split operations.

In any case, I only have enough time to split 1-5 nodes every frame - which is a pretty tight budget. Maintaining full detail with this budget requires a priority model more advanced than typical, and a further seperation of the quadtree that is used for rendering and the quadtree that is stored in memory can help considerably, so that you can eliminate the overhead down to just a texture download. It needs visibility eventually - an overdraw of 3 means you are using at least 3 times as much texture memory as you could be using. (With a perfect mapping and no overdraw, 16 megs of texture memory should be sufficient to texture the full viewing sphere at 800x600)

On current systems, the texture download is slow enough that rapid flicks of the camera are going to result in a noticeable loss of detail - and its hard to completely hide this. But future systems should remove this limitation with the advent of AGPx4 and faster buses and texture download rates. Nvidia says they are going to greatly improve their download rate in NV20.