Jump to content
  • Advertisement
Sign in to follow this  
ZealousEngine

Infinite terrain advice...

This topic is 4690 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

Im using a language called darkbasic (a simple yet powerful engine that uses dx), so im not sure how much you guys can help, but any insight/theory would be appreciated. In a nutshell, im trying to create a infinite terrain system. Right now I have a 16x16 grid of terrain chunks, and I shift chunks from one edge to the other as you move. Updating the shape of the chunk, retexturing, ect... is all spread out over a smart queue so theres no dip in fps. Since the terrain is square in shape, you can just wrap one end to the other, so you can walk forever and never hit a invisible wall. For LOD, since I dont have total control over the engine or directx, I cant do anything too fancy. Basically what im doing now is just stacking multiple mesh resolutions ontop of each other, then hiding/showing the different meshes based on distance from the camera. A waste of memory yes, but not too bad (the higher res meshes are only for say 4x4 chunks, since theyre only shown in a small radius around the camera). My question is, do you guys (the big boys :) ) see any problems with this system? How different is it from a 'real' (ehe) engine? Again, it seems to work pretty well, just thought id see if you guys had any advice. Thanks in advance for any input! *EDIT - Forgot to mention, I use ribbons to patch the gaps inbetween LOD tiers. I researched lots of different terrain types and patching techniques and think this one is the best. If you are careful with your LOD distances you cant even see them, and no krazy triangle splitting or geomorphing is required (which I prolly couldnt do anyway). Also right now each chunk is a individual 'object' (in darkbasic a object is a 'entity' with its own mesh, texture, ect...). Im toying with the idea of merging all chunks for a LOD tier into a single object. Thus each terrain chunk will be what darkbasic calls a 'limb' (a individual mesh of a object, a sub object if you will). Since single objects are typically faster/better than many objects (makes sense if I understand the basics of the whole rendering process). Hope that made sense :/ [Edited by - ZealousEngine on January 11, 2006 4:50:16 AM]

Share this post


Link to post
Share on other sites
Advertisement
Heres some screenshots. Hopefully these will give me a little street cred :p

This is a birds eye view of the 'shifting chunks', you can see the different LODS
Clicky 1


This ones just pretty I think
Clicky 2



[Edited by - ZealousEngine on January 11, 2006 5:50:48 AM]

Share this post


Link to post
Share on other sites
Well I got the links to be clicky (my html was a little rusty ehe). But I cant get the image to display. I guess you cant do that with a image shack image. oh well...

Share this post


Link to post
Share on other sites
:) 'real' engines don't have infinite terrain, so the requirements are different and they ususally go with some static structure with a quadtree or somthing

I was doing infinite terrain too, for an arcade style game where it makes sense to go forever...
And I came to Exactly the same conclusion you did. Pretty much the same system. Nice to see that you came up with the same terrain wrap-around reuse scheme, its clever.

On another note:
I'm curious how you are generating your terrain data?
I'm using a modification of Diamond Square algorithm (modified to allow generation over edgeless terrain)

Share this post


Link to post
Share on other sites
Quote:
Original post by Libvan
This article might help you.

http://www.drizzle.com/~scottb/gdc/continuous-world.htm


Actually, that article is in regards to "Continous" worlds. Not Infinite.
It discusses how they use more or less a giant portal system to allow level artists to create and join separate map areas as needed without having interdependance.

This is different from what ZealousEngine is trying to accomplish, he wants infinite terrain - infinite meaning he cannot afford to have an infinite number or level artists constantly making new areas to add on.
He is asking about Procedurally generated terrain, where the terrain is infinite because it is created on the fly by the program as you move across it.

Share this post


Link to post
Share on other sites
Quote:
Original post by haphazardlynamed
Quote:
Original post by Libvan
This article might help you.

http://www.drizzle.com/~scottb/gdc/continuous-world.htm


Actually, that article is in regards to "Continous" worlds. Not Infinite.


Instead of your resource thread loading data off the disk just have it generate data and you now have an infinite world with that system. There are no infinite worlds only worlds that appear to be infinite.

Share this post


Link to post
Share on other sites
Well to clarify, things dont HAVE to be 'infinite', things CAN be pre generated (like they are now). At some point I may implement some form of 'on the fly' terrain generation, object placement, ect... Im sure I could do it (I have some experience with perlin noise), but right now its not crucial.

So, right now the way I get my 'data' is just from disk. Each terrain chunk has its own pre calculated heightmap, object map (where trees and buildings are), detail map (random seeds that place grass), ect... So these individual data files are loaded when a row shifts from one edge to the other, works great. Today im working on a per pixel splatting shader (yeah darkbasic can utilize hlsl fx shaders :) ).

@ haphazardlynamed - Im glad to hear my system isnt that unheard of. I was afraid you guys would think its uber ghetto noobish :). I HEAR this is how magic carpet did their 'continuous' terrain.

@ Libvan - Yeah I read that article about dungeon seige. Didnt see too much that related to my system but it was a good read.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
His current method of generating and Wrapping terrain data is already pretty optimal. It doesn't justify the ovheead or complexity of the areas and 'doors' approach used in Dungeoun Siege; a large factor in the way they organized their world had to do with supporting massive numbers of networked players at once. And this is not a concern here.

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!