Heheh, so my years of C coding is showing through.. *sigh*

The parenthasis around the digits in the #define macro are a C coding style. It forces the macro to be atomic, so there are no questions about its use in an expression.

The bitshift used in the definition of variance is based on the size of a full binary tree for a given depth. A binary tree of depth 1 is of size 1, for depth 2, it is of size 3, depth 3 is of size 7, 4 == 15, 5 == 31, etc.. This corresponds to 2^depth. Thus the shift calculates how many nodes will be needed for a tree of depth VARIANCE_DEPTH. (in this case, 9)

I'm new to LOD, but I think I'm starting to get my brain wrapped arroud ROAM (great article by the way ) I have a couple questions thoug..

I read somewhere that split/merge, frame coherent implementations of ROAM are slower than split-only implementation.. This makes no sense to me.. I though a split-only version would require more split operations, because the whole tree has to be rebuilt. ?

If I choose to go with split/merge, is there really a need for 2 separate queues? Couldn't I just use the variance tree as a queue, choose the diamond with the lowest variance when I need to merge, and the one with the highest variance when I need to split?

Tough question. I've read several articles describing the problems with ROAM split / merge implementations. Since I have not tested this directly, I can only agree with them on an intelectual level.

So, back to your question. Split/Merge is not slower than Split Only. The articles discussed Split/Merge versus other frame coherent methods, not Split/Merge versus Split Only.

The queues are required because the Variance Tree only has surface roughness information, not distance-to-eye or desired resolution. The actual Split Metric takes this additional data into account on top of the surface roughness.

The queues thus hold the calculated information about what triangles are not only roughest, but also closest to the eye.

Thus, when splitting with the priority queues, you will always split triangles by their distance-to-eye first then by roughness.

Aw, is that spike back again? I could have sworn it was fixed for the demo... Last time I fixed it, it was accessing the byte directly after the HeightMap.

I fixed this as part of an optimization by adding another row at the beginning and end of the Height Map which wrapped the terrain correctly. For some reason I guess this didn't fix it on your end? Odd. I'm using a completely different engine now and it has the same error (different reason tho).

As for the view position, that should work fine, I'm using absolute value around the distance calculations. The distances should be correct regardless of negatives.

If this is truely a problem I suggest moving all your landscapes to be in the first quadrant, so you won't have negative view positions. This was the intention when originally designing the class, but there is no mention of this in the article or code (my fault). Still, the distance calculation should be working..