Hi, I have small terrain engine running nicely, complete with texture blending and geoclipmapping: Now I want to expand the game world massively. I am primarily interested in near-seamless play. I would love your comments on my intended methodology before I plunge in. WORLD = large array of SECTORs, SECTOR data held in individual files ACTIVE TERRAIN = 3 x 3 grid of SECTORs SECTOR = QUADTREE of 8 x 8 LEAFs LEAF = 17 x 17 vertices ( 17x17, 9x9, 5x5, 3x3, 2x2 ) = 16 x 16 cells ( 16x16, 8x8, 4x4, 2x2, 1x1 ) Therefore: Size of ACTIVE TERRAIN = 24 x 24 LEAFs = 384 vertices x 384 vertices x sizeof(sTerrainVertex) (44 bytes) = 6.5MB Sounds bearable for VRAM? Main SECTOR is the one the player is in, the other 8 are the surrounding ones, also held in memory. As the player crosses into the neighbouring SECTOR, beyond a certain buffer zone, the SECTORs now 2 SECTORs away discarded and the new neighbouring SECTORs are loaded in their place. There is a single VB for the whole terrain. The SECTORs are paged into and out of this VB as required. Each sector has its own quadtree. Culling occurs like this? loop thru SECTORS (only present and neighbours) { Is SECTOR visible? { test SECTOR node of quadtree recursively Render Objects in SECTOR } } Your thoughts appreciated. Thanks Simon

Its basically the engine used in a 2d scrolling tile game isnt it, just extrapolated,

I am beginning to see why games use lightmaps etc.

There seems to be so much done at init at present, which now will have to be done druing runtime, like normal averaging for the terrain.

Maybe I'll have to ditch the dynamic lighting, or employ some funky pixelshader version!

Are you sure you implemented geo-clipmapping? I can hardly tell from the screenshot. It's very misleading. Did you read the paper? It talks about the compression and prediction from mip-levels to make it possible to load huge data.

I'm about to implement a continuously loading terrain not for air but for ground units. However, I'll integrate a hysteresis to avoid sudden reloading requests when the unit turns and walks back just behind a sector border. Moreover I have a "sector width" as buffer to give the engine enough time to build up the new sectors. With such a mechanism I'll need 8 by 8 cells (or sectors) in memory.

You may be interested in reading this thread, where I've described my thoughts a bit more in detail:
http://www.gamedev.net/community/forums/topic.asp?topic_id=373486

Hmm,

This came up before.

To nit-pick, I thought Geomipmapping used precomputed sections of terrain at different LODs, hence the texture mipmapping parallel, while geoclipmapping used dynamic terrain, which computes its data at runtime.

I am sure someone will correct :)

Thanks for clarifying that for me john, it IS geomipmapping that I have done, I was confusing it with Chunked LOD.

However, the clipmapping approach is much more interesting I think. I'm beginning to forsee the problems in my present approach that Valor Knight refers to.

More research needed!