easiest way to build large worlds?
Author
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?
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
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
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.
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.
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...").
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...").
Quote:Original post by ArKano22A smoother approach is to divide the world into smaller chunks, and seamlessly load/unload just outside the player's view.
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...").
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.
You might find that the engine already supports maps as large as you mention in your post.
Author
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.
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
- 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
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.
Quote:Original post by DaivukIt is, however, a perfectly good modern technique if you implement it on the GPU with VTF (vertex texture fetch).Quote:Original post by medeThis 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.
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 topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
