Jump to content
  • Advertisement
Sign in to follow this  
sipickles

My plan for extremely large terrain - the right approach?

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

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!