Originally posted by knackered:
there’s no need to be so enthusiastic in your destruction of zulfigar’s work, jan.
Sorry, it wasn’t meant to sound that way.
About the stitching: I don’t know of any link. As i said, it’s in Game Programming Gems 1, 2 or 4 that’s for sure. However, i don’t have access to my books right now, so i can’t be more specific.
After i started working on it, i bought Far Cry and downloaded the SDK. With it comes their editor, and in wireframe you can clearly see, that they use the exact same method as described in the book, with a patch-size depending on the maps size (on a typical map, the patch size is 64*64 vertices).
I think that it is not a good approach for “scientific” cases (depending on your definition of “scientific”), because it is meant to be a low-overhead, realtime-capable LOD approach. To actually make it realtime and reduce calculation overhead to a minimum you need to live with one disadvantage: heavy popping.
No matter how you tweak your parameters to make it less obvious, your terrain will still pop when the LOD changes on a patch, and it WILL be visible and noticable. Though, for a game it might be acceptable.
However, in a “scientific” scenario, you will most certainly want to have a LOD method, that also minimizes the differences between LOD levels.
And there are plenty of other methods, that do just that and are therefore better in such cases.
But as i said, for games, i have not been able to find any other method that comes even close to this one. And as a prove of concept, take a look at Far Cry.