# Almost complete GeoMipMapping solution, couple of questions

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I am currently nearing the completion of a program for terrain rendering using the Geo MipMapping LOD algorithm and had a couple of queries. My first question regards the changing of GeoMipMap levels, I currently simply change the GeoMipMap level depending on the distance from the camera to the terrain blocks centre. Having read the GeoMipMapping paper by Willem de Boer it becomes apparent that there a more algorithmic approach should be used for choosing whether or not to change GeoMipMap levels, the problem is I don’t really understand any of the equations he lists. Don’t suppose anyone could explain them in non mathematic English for me? My second problem is that I am currently changing GeoMipMap levels but I am not taking any steps to avoid getting terrain cracks. I understand the theory that certain vertices should be ignored in order to make the separate terrain blocks match correctly but am not sure how to implement it. Currently my terrainBlock stores 3 index buffers for a 16*16 block at 3 different GeoMipMap levels, surely I don’t have to store more index buffers for each scenario where a neighbouring block has a lower level of detail? That would mean something like a total of 16 possible index buffers for each GeoMipMap level so roughly 48 index buffers per terrain block. Is there a way to ignore the specific vertices at the edge of the terrain block without having to create an entirely new index buffer? Thanks a lot for any help.

##### Share on other sites
I do not see how you can do that without having to use a separate index buffer.

However, you only need 1 index buffer per different scenario, because the same index buffer can be used with all the patches.

Also you may further optimize your index buffer by using just 1 single index buffer and offsetting into it for different LODs.

##### Share on other sites
Explain how you can offset the index buffer to achieve this? I recently finished my terrain engine and I had to use multiple index buffers for each possiblity.

##### Share on other sites
I'm assuming he meant have the first 30 indexes for the first level, next 20 for the second level and next 10 for the last.

Then you can render 30 vertices starting from vertex 0 or 20 starting from vertex 30 or 10 starting from vertex 50.

Hope this is clear :).

##### Share on other sites
Quote:
 Original post by hoogie... Having read the GeoMipMapping paper by Willem de Boer it becomes apparent that there a more algorithmic approach ...

Rather than using a fixed distance as a threshold, the threshold is the value (in pixels) of the maximum change in the height of the terrain. The change in height in pixels can be computed given the distance, screen size and FOV. Frequently, to lower the amount of processing required, the screen size and FOV are fixed (or assumed to be fixed) and then the distance is computed using those values. The result is that each level of each patch has a different distance threshold that depends on how much the height of the terrain varies between two levels of the patch.
Quote:
 Original post by hoogie... I am not taking any steps to avoid getting terrain cracks. ...

One way is to create geometry (a "skirt") around each patch to hide the cracks. This is the simplest way to do it with respect to coding, but it adds a lot of geometry.

Another way is to always keep the number of vertices along the edges of the patch constant. If your patches are fairly large, then this may be a good solution. However, the lowest resolution meshes for a patch will still contain a large number of vertices. If the patches are not large, you won't gain much by using LOD. Also, the code to generate the index buffers will be a little complicated.

Finally, another solution is to vary the number of vertices along the edge of a patch depending on the resolution of a neighboring patch. This and the "skirt" solution are the most used. This solution will result in a large number of index buffers, but keep in mind that index buffers are relatively small and it isn't 48 index buffers per patch, it is 48 index buffers total (since every patch uses the same set of index buffers). Another drawback is that this complicates the level selection for a patch. Rather than just being based on distance (or amount of pop), it is also dependent on the levels of adjacent patches.

• 17
• 11
• 12
• 9
• 49
• ### Forum Statistics

• Total Topics
631394
• Total Posts
2999756
×