Sign in to follow this  
sipickles

My plan for extremely large terrain - the right approach?

Recommended Posts

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

Share this post


Link to post
Share on other sites
This is basically the same idea as I'm thinking about implementing in my engine. :)

So it has to be good! ;)

Are you planing on doing a totally seamless world with no loading what so ever? I am, and my thoughts would be to simply have a separate thread that loads all terrain data during runtime - i.e the outer "boxes" gets loaded and freed all the time... hopefully this wont take to much time to complete. :D

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Geo-clipmapping is a technique for displaying massive terrains. The papers describe the entire algorithm very thoroughly. In fact, one of the terrains they render is 216,000 x 93,600. Maybe you mean geoMIPmapping, instead of geoCLIPmapping. It's unfortunate that the names are so similar.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
Original post by sipickles
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.

No. These names refer to specific algorithms. You can find the papers that describe the algorithms (and others) here: www.vterrain.org

The major ones:

Chunked LOD (not to be confused with "CLOD")
Ulrich. Chunked LOD: Rendering Massive Terrains using Chunked Level of Detail Control

Geomipmapping
de Boer. Fast Terrain Rendering Using Geometrical MipMapping

Geoclipmapping
Losasso & Hoppe. Geometry clipmaps: Terrain rendering using nested regular grids.

SOAR
Lindstrom & Pascucci. Visualization of Large Terrains Made Easy

ROAM
Duchaineau, et al. ROAMing Terrain: Real-time Optimally Adapting Meshes

Share this post


Link to post
Share on other sites
I had a terrain engine running that loaded up a 3x3 terrain block, the loading worked fine, but since it was using threads, It was really dropping my fps, so I took it out so that I can get everything else running fast first and then put it back in. I was just using 9 terrain maps and 9 quadtrees for the map, when the thread class was sent new info it was queued up and would load/unload everything on the next pass it would run. I doubt I did it a good way, it was mostly a hack - I ran into problems with data protection (hopping back and forth on the terrain tiles too fast) and the camera flashed when I would reset the terrain to the orgin (it is do-able, but It would take time).

[Edited by - Valor Knight on March 6, 2006 8:04:34 PM]

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
One thing to keep in mind when you are designing this.. is that with a huge seemless world you have to make it so that 'there is no world space'.

You have to use specific tricks regarding worldspace as once you go too far out into the world you will lose precision and render/animate incorrectly. There are various resources to read about solutions to problems like this. I know one of the GPG books have an article regarding this, and Scott Bilas also has a powerpoint slide.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
One thing to keep in mind when you are designing this.. is that with a huge seemless world you have to make it so that 'there is no world space'.


How I did it is the player was always on the center terrain, once the player moved to an ouside terrain, that terrain was recenterd to the middle and the camera was placed accordingly. However this caused a camera flash in my program, which I am sure was caused by the incompleteness of it. Its do-able, but will take a long time. Now that I am working on a scene graph, I can only imagine how that would complicate things even more.

Share this post


Link to post
Share on other sites
I'm researching the same topic and yesterday i have found this article :
http://iparla.labri.fr/publications/2005/PM05/

I have not read it yet but i think it's what you need.

Hope it helps.

[Edited by - Ivo Leitao on March 8, 2006 7:16:46 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this