• Advertisement
Sign in to follow this  

easiest way to build large worlds?

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

I understand that this is not going to be easy, but I am just looking for an easier way of doing so. I plan on building a game based around adventure, so the world in the game is going to be huge. By huge I mean at least 10 miles x 10 miles. So far, I think my first idea is to build a 3d world, but have the camera in an isometric view. This way, all buildings and cities will really only need to have 2 sides to them instead of 4. Is there any other ideas on building vast places in 3d? Would it load just as fast as say the isometric idea that I had? Also, should I render the land itself with height maps if possible?

Share this post


Link to post
Share on other sites
Advertisement
i actualy trying some techniks which goes in the same direction.
i implmented geometrical mipmapping which is a technik to reduce the level of detail of the terrain mesh dependet to the distance.

http://flipcode.com/archives/Fast_Terrain_Rendering_Using_Geometrical_MipMapping.shtml

because you cannot map a single texture one such a large surface, you can use a shader to compose different small texture like snow,stone,grass,sand with a mapping texture or dependet on the slope of the terrain

http://www.cs.auckland.ac.nz/~jvan006/multitex/multitex.html

Share this post


Link to post
Share on other sites
You seem to be talking about a huge open space streaming 3d world ? This is indeed a very big task. Especially when the times come to populate this world with assets.

Games such as FarCry2 and WorldOfWarcraft managed to do huge world very close to 10 miles x 10 miles and they didn't have that limitation of isometric view.

You shouldn't care where the camera is located or how it views the world.
1- Make your world as nice as possible.
2- Make the camera as "fun" for the player as possible (make sure the players is ok with the isometric movement limitiation)
3- Optimize.


By Optimize I mean :
-If there are sides that you KNOW will never been seen, you can cut them.
-Do lots of clipping. If you don't see it in the frustum, it should not be draw (or maybe even not updated at all in some cases)
-If your FPS still sucks : do LODs (level of details) for the terrain, models or animations.

Share this post


Link to post
Share on other sites
As crucifer said, the best way to render a large world (even a medium world) is to cull like crazy. Never draw anything that the player can´t see (nothing should be drawn outside the camera), try to reduce detail on things that are far away from the player...

And the other issue with worlds this big is memory. You could try to divide the world into "quadrants" or chunks and have only in memory the current quadrant and the 8 neighbours. When the player moves to one of the 8 neighbours, unload the previous ones, calculate the new neighbors and load them from disk (maybe a small pause in game, show "loading...").

Share this post


Link to post
Share on other sites
Quote:
Original post by ArKano22
You could try to divide the world into "quadrants" or chunks and have only in memory the current quadrant and the 8 neighbours. When the player moves to one of the 8 neighbours, unload the previous ones, calculate the new neighbors and load them from disk (maybe a small pause in game, show "loading...").
A smoother approach is to divide the world into smaller chunks, and seamlessly load/unload just outside the player's view.

Share this post


Link to post
Share on other sites
You might want to take a look at the approach used in the cube2 game engine. In this engine the world consists of an octree of recursively sub-divisible cubes. The engine currently holds the entire world structure in memory. But even with this implementation the size of world supported is massive. To support arbitrarily large worlds you could simply augment the engine to dynamically load/unload branches of the octree world structure as needed. If you were to use the cube2 engine you would likely need to do a little fancy coding to split the lightmaps so that they only apply to individual branches but overall it shouldn't be too difficult.

You might find that the engine already supports maps as large as you mention in your post.

Share this post


Link to post
Share on other sites
Thanks to all who replied. I like the idea of having it where the player can only see so far in one direction, and as they get closer load (as in world of warcraft). I also liked the idea of divide everything, so there would be a slight pause when entering a city. Not sure if that would irritate people or note (I think it would, like in Ragnarok online). I do plan on having it be an online game, which is why having the FASTEST way to load a HUGE world is a major concern.

Share this post


Link to post
Share on other sites
If you look at GTA, you could divide the world into streets and buildingblocks. Each chunk could have multiple LOD levels. For example:
- full detail, all textures/shaders -> your nearby area
- medium detail, small details/entities gone, simplified shaders -> neighbour area's
- low detail, less polygons, only a few textures, no small details. And possibly geometry removed if you can't see it from that point anyway
- super low detail. Only for huge buildings/mountains that can be seen in the far distance.

For each chunk you can make a listing of which other chunks are (possibly) visible and in which state. In GTA lot's of the streets and smaller buildings are hidden behind skyscrapers, so you can skip lot's of it. Use a large octree or something to store your chunk references in so you can quickly sort out in which chunk your player/camera is.



With a background thread, you can load a chunk to its desired state (eventually stick with the previous lower detail models if you're not done loading yet). In this thread you can load geometry, entities, textures, maybe lightMaps, and so on. When the chunk is not needed anymore, you can dump its contents to keep friends with your memory.

The difficult part is, besides from multi-threading, making a smooth transition between 2 states. When driving towards a skyscraper, you don't want it to suddenly change into another (better) model. However... if you decide to keep a fixed isometric view, you can load outside your view.

Good luck,
Rick

Share this post


Link to post
Share on other sites
Quote:
Original post by mede
i actualy trying some techniks which goes in the same direction.
i implmented geometrical mipmapping which is a technik to reduce the level of detail of the terrain mesh dependet to the distance.

http://flipcode.com/archives/Fast_Terrain_Rendering_Using_Geometrical_MipMapping.shtml


This is an old technique, and it's not very friendly for today's hardware. You basically need to recreate the mesh every time. Very CPU time consuming, and lot of upload to the video card.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daivuk
Quote:
Original post by mede
i actualy trying some techniks which goes in the same direction.
i implmented geometrical mipmapping which is a technik to reduce the level of detail of the terrain mesh dependet to the distance.

http://flipcode.com/archives/Fast_Terrain_Rendering_Using_Geometrical_MipMapping.shtml
This is an old technique, and it's not very friendly for today's hardware. You basically need to recreate the mesh every time. Very CPU time consuming, and lot of upload to the video card.
It is, however, a perfectly good modern technique if you implement it on the GPU with VTF (vertex texture fetch).

Share this post


Link to post
Share on other sites
I like a lot of these ideas and soon I will be able to pinpoint exactly how I'm going to do this (using some techniques provided in this thread).

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Daivuk
Quote:
Original post by mede
i actualy trying some techniks which goes in the same direction.
i implmented geometrical mipmapping which is a technik to reduce the level of detail of the terrain mesh dependet to the distance.

http://flipcode.com/archives/Fast_Terrain_Rendering_Using_Geometrical_MipMapping.shtml
This is an old technique, and it's not very friendly for today's hardware. You basically need to recreate the mesh every time. Very CPU time consuming, and lot of upload to the video card.
It is, however, a perfectly good modern technique if you implement it on the GPU with VTF (vertex texture fetch).


i saved the meshes in a file because they never change. then i handle them like LOD shapes of other static objects. the memory consume of the lower meshes is much smaller than the ones of the original shape so it is not a big issue to have 2-3 meshes for every cell. i think this is even faster than to work with vertex shader because for cells farer away i have to pass much less vertex (data) to the graphic card. because the vertices at the borders of a low detailed cell are identical to the one with higher details i can change the mesh for a cell without any additional computation.

for sure i need dynamical memory management but this is more because of the original mesh and texture data.

at the moment i thinking about to handle cells which are fare fare away with somethink like billboards. to have e.g. a skyline with mountains !? think it should possible to render the horizont to a texture because this will only have small changes in relation to the move of the camera.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by ArKano22
You could try to divide the world into "quadrants" or chunks and have only in memory the current quadrant and the 8 neighbours. When the player moves to one of the 8 neighbours, unload the previous ones, calculate the new neighbors and load them from disk (maybe a small pause in game, show "loading...").
A smoother approach is to divide the world into smaller chunks, and seamlessly load/unload just outside the player's view.


I actually do something like this on the game i'm working on.

Basically, i have Sectors that hold 5x5 (or 25) 512x512 chunks each, and i load the sector the player's at and it's 8 neighbours, and whenever the player moves, the player's Spectator requests for revalidation of sectors.

If the player changes sectors, the sector revalidation will unload the sectors that do not belong in the network (the active sector and neighbours), and will load any new sector in a thread.

Since the sectors are pretty big, there're no "oh gee this thing just popped into view" effects.

Also, to validate whether a sector is visible or not, i do a Frustum-AABB test (no fancy quadtrees or anything) on the sector's AABB.

That way i can prevent any visibility test to the chunks while loading/unloading, since only the sector is necessary for testing, and i can optimize rendering by having a geometry buffer containing only the visible chunks' geometry, which is recreated if any chunk is no longer visible or if a new chunk is visible.

Share this post


Link to post
Share on other sites
Once upon a time there was a great article written by Scott Bilas, titled "The Continuous World of Dungeon Siege", which gave some insight on how the terrain loading was managed by Dungeon Siege. Unfortunately the original site which hosted the article is down (http://www.drizzle.com/~scottb/gdc), but you can still find the presentation slides on the subject here.

The idea was that the entire world was broken down into smaller nodes or sub-terrains. From memory, the asset and terrain loading was managed in a separate process independent of the game engine. It kept track what parts of the map should be cached in memory and loaded them in the background as the player was about to cross nodes. The article went into greater depth about the potential problems of large terrains, such as numerical stability issues, etc.

ps. If anyone has a copy of that article please let me know.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement