Hello :-) I recently started to implement geomipmapping (ref : "Fast Terrain Rendering using Geometrical Mipmapping" by Willem H. de Boer) but i have some troubles to understand one part... Since, every frame i update the patches i have to say which level of detail a patch will have. But here is the problem, actually the only way i found to update the level of detail is "hardcoding" distances and depending on them the level of detail change... As stated in the whitepaper there is a method... unfortunately i have troubles to understand it. Maybe someone can help me out ? How can i do to update the level of detail in a "nicer & robust" way than hardcoding distances ? Thx in advance :-)

-Simplest way is to just use some function of distance. Something like LOD = floor(distance/200.0f); (here LOD-0 is full resolution).
-A bit better method would be to project AABB of patch/node to screenspace and use this as input to LOD selectiong function. Bigger on screen => better LOD.
-Use both plus some heuristics.

Hmm, i'm quite lost in your explanations =)

Could you explain it more precisely please ? ;-)

(sorry)

The de Boer method is quite complex. As I understood it, it worked something like this.

In geomipmapping we have a set of square patches of a given number of vertices in width. In order to draw as few triangles as possible we sometimes skip vertices that we don't think are needed. For example, if I had a patch

A-B-C|\|\|D-E-F|\|\|G-H-I      (viewed from above)At a lower level of detail I would only drawA---C|\  || \ ||  \|G---I

The computer only draws straight lines. Therefore in the lower level of detail the height that was at B is now a linear interpolation between A and C. The de Boer method is to do that interpolation in code, finding all the lower level of detail heights, and comparing them to the actual heights present in the higher level of detail. He then presents an equation to project these discrepancies into screen space, assuming we are viewing the map from the side. Assuming we have defined a maximum pixel error, we can therefore rearrange this equation to find the shortest distance from the camera that we can switch to the lower level of detail and not exceed our maximum pixel error.

In practice I found this method to be a little overzealous. It sounds appealing, but the algorithm can get ugly quickly (or perhaps it's just my code), and the assumption that we are always viewing from the side of the patch, along with other slightly more complicated inaccuracies inherant in the idea means that it's really not worth the effort for the most part.

I agree with Darkwing, a simpler, more directly distance-based approach would work. The line

LOD = floor(distance/200.0f);

would be somewhere in the function that chose the level of detail for the patch every frame. It means, "divide the distance to the patch by 200, and round the result down to the whole number immediately beneath it." In practice, you'd need to clamp this to some maximum value so you never requested levels of detail which you hadn't created.

Darkwing's second suggestion is a simpler form of de Boer's approach, and probably makes more sense. It sounds like a good idea. Find a box enclosing all the geometry in the patch, and use an equation like the one mentioned by de Boer to work out how large it would be when drawn to the screen. If it is tall, you'll need a high level of detail as the terrain is likely to be varied. If it is short, a lower level of detail will do, as the terrain should be fairly flat. To be clear, that's a logical way of explaining what's going on, but in practice you will have to rearrange the screen projection equation to get the shortest distance at which the height of the box does not exceed the maximum pixel error. Almost exactly the same as de Boer's method, but a little less accurate. On the upside however, you should get broadly similar results for reasonably sized patches and it will probably be a lot easier to program.

Hope this helps.

John.

Thank You Hamster ;-)

It now make much more sense for me !