Archived

This topic is now archived and is closed to further replies.

rhino

GeoMipMaps for terrain?

Recommended Posts

I recently read William H. de Boer article and it seems quite interesting: http://www.flipcode.com/tutorials/geomipmaps.pdf I am wondering if anybody has tried implementing this and what kind of results did they have had? The premise seems sound, it should spend very little CPU compared to algorithms like ROAM or adaptive quadtrees, taking advantage of the faster and faster GPU''s by getting a "rough" paired down set of poly''s into the pipeline asap. It will obviously use a little more memory, but that''s not a primary concernt using the engine I''m using (WildTangent web driver). I need to keep CPU use down to a minimum. However, I can''t find any implementations of this, the E-mersion project seems dead (the website has been down for over a week), and all emails to Mr. de Boer''s old address no bounce. It doesn''t look hard to implement, I just want to know how well it''s worked for anybody before spending the time. Any feedback most appreciated! Thanks, Rhino

Share this post


Link to post
Share on other sites
So...nobody has tried anything like this geomipmap idea?

To summarize it:

- the full detail terrain is broken into square tiles of N verts per side (N must be a power of 2 + 1, for example 5, 9, 17, 33, etc). The distance between verts is consistent.

- the lower detail tiles are simply binary divisions of the highest detail tile. For example, if tiles were 17 verts per side, then there would be 5 total levels of detail maximum:

17, 9, 5, 3, 2

- all tiles are pre-generated at design time, and all tiles are loaded into memory at runtime. A bounding box which covers the maximum extends of all tiles is also pre-generated at design time, as is the maximum vertex error for all verts in all LODs.

- a lookup table is pre-generated at design time PER TILE so you can quickly determine the max screen pixel error per tile based on distance. This can be done since it is assumed that the camera view is horizontal (perpendicular) to the terrain at best case. This results in display too high of detail at extreme slope camera orientation, but the key to this algorithm is trying to get tri''s to the GPU as quickly as possible, not trying to come up with a perfect reduced list.

- a simple quadtree is used for culling and space partitioning, with the leaves being the actual tiles. Since the bounding box of the tiles were pre-computed, you can quickly cull out tiles on a per-frame basis.

- for the tiles left in the view, the appropriate LOD is picked based on distance from the center of tile.

- for adjacent tiles of different levels of detail, excess verts in the higher detail verts are tossed and the tri''s stretched, to create a perfect seam. Since this is a binary reduction/expansion between adjacent tiles of differnt levels, this is easy to do (low cpu to compute)

That''s pretty much it. I glossed over a lot of details, but they are in the article linked above. It seems like it will work really nice for FPS games where typically you can''t get an insane elevation. The main focus of the algorithm is to get poly''s to the pipeline as quickly as possible, and spend a minimum amount of time in the CPU.

Any thoughts or feedback on this? Has anybody coded up something similar, and if so how did it work?

Thanks,
Rhino

Share this post


Link to post
Share on other sites
Our game''s terrain engine uses an algorithm very similar to this one. It''s very efficient, you can load big parts of the terrain (incl. LODs) into the onboard memory of the 3D card. It doesn''t stress the AGP bus, that''s a big plus since this is often an important bottleneck in today''s 3D applications. Geomipmapping is ways better than ROAM/CLOD and all that older stuff, esp. for rendering on modern 3D hardware. I can fully recommend it.

And it can be easily tweaked to get geomorphing between the different LOD sets.

/ Yann

Share this post


Link to post
Share on other sites
Yeah, we are using a similar algorithm as well. All the vertices are stored in a vertex array, and indices for each LOD are just generated as needed. It faster than ROAM etc., but caution, it should be used for static geometry. It works really well, producing very little artifacts (provided the tolerance is reasonable) even if you dont use trilinear filtering.

Share this post


Link to post
Share on other sites