Sign in to follow this  

Infinite terrain advice...

This topic is 4354 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
:) '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
Oh.
Okay then.

I'll mention then... That in my own terrain, which is generated on the fly, not loaded; a big problem I found was that, generated terrain can be very Boring since its all so similar to itself. Thats one of the main reasons why the program is collecting dust while I work on other stuff....

I have been thinking however, that it would be nice if I could have 'Areas of Interest' where the terrain is artist designed, with buildings and game objectives and stuff; while the generated stuff is used to fill-in details between Areas of Interest. However I haven't thought of a good way to have the chunk system decide if it should Gen or Load without doing an annoying search thru some Area of Interest listing every time it needs a new terrain chunk...

Just an interesting problem to think about if you decide to eventually go with some kind of hybrid terrain like that....
Your's would be approaching the issue for the Other direction than mine, you already have the Designed areas, but not generated ones


Share this post


Link to post
Share on other sites
@ haphazardlynamed - Ysaneya talked about just that in his dev journal you should really check it out. He designated special areas called DEMs (not sure what it stands for). Basically they were pre calculated areas that were placed randomly around his world. Its supposed to give things a 'unique' look, I imagine it works quite well.

In short, you should sprinkle in some pre generated stuff to your world to make it look less boring :)

Share this post


Link to post
Share on other sites
Heres another theory ive been thinking about, maybe you guys can give me some advice.

Right now my detail system (grass, rocks, ect...) is setup like this - I have a 'object' that consists of say a couple hundred lil meshes (cross plains in this case). Rather than position a bajillion little detail objects around the camera, then try and frustum cull them, I do something a bit different.

Every frame, I start with the first detail object, and start placing things outward from the camera (always making sure things are inside the frustum). When items get too far from the camera, or I run out of things to place, I stop. So in short, I have no preplaced objects in my scene to cull, they are all positioned every frame, in 'real time' I guess you could say.

Positioning 250+ cross plains (including all the frustum checks) takes less than 2ms!

So, this got me to thinking, do you think it would be wise to use this method for ALL my objects (trees, buildings, ect...)? I could just check the area youre in, and make sure you always have x number of trees, y number of crates, ect... and load/delete as necessary. Think it would work?

Share this post


Link to post
Share on other sites
Sorry, no real input to the thread other than I've always found this to be my favourite demo of an infinite terrain - by Humus. I haven't read the brief so can't comment on the implementation. You will have to do that by looking through the docs/source.

Clicky

F451

Share this post


Link to post
Share on other sites

This topic is 4354 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.

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