• Advertisement
Sign in to follow this  

how to store maps in 3D?

This topic is 4041 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, Sorry if this is a common question, but I can't seem to find much on google or the forum search..... How are maps typically stored in a 3D game? In 2D, I would just use tiles and then I also had 'free floating' objects as well... so i would have a tile map layout then a list of x/y/w/h.... How does it work in 3d though? Do I still use some sort of tile system? Should every object have all its vertices's and I draw like a paint brush in the editor like in q3? so it would be for each object all the vertices's/texture/any other properties.... does that sound right? Any links to articles on this are appreciated.

Share this post


Link to post
Share on other sites
Advertisement
The only thing is I'm attempting to make an RPG, so I don't think BSP is the best format for me... won't I be limited to making enclosed scenes? I was a mapper for Quake 3 back in the day and I remember you had to do tricks just to keep the FPS high....

Share this post


Link to post
Share on other sites
Thanks for the replies...

I think 'heightmap' was the exact keyword I needed here... [grin].

After doing some googling, I'm thinking that I can represent my map like this:

1) height map
2) quad-tree
3) 'free floating' models... this is basically a 'center of gravity', length/width/height/texture/model
4) 'free floating' objects... these are objects I can draw with a brush, q3 style.. these have the same properties as the 'free floating models', but no 'model' property.....

I'm thinking something like this should work.... The game is an RPG, which will have city-like areas... for those maps, I suppose the heightmap will be mostly flat... but this shouldn't matter, right?

The one thing I really can't figure out is what data I should use to represent the 'free floating models' and 'free floating objects'.... If I want to represent say a monster in my world, what data do I really need?

Should pure BB collision and geometry suffice for me, or will it be real poor looking? Do I store 2 sets of geometry, one for the collision area and one that actually stores the models vertices?

Thanks again..

Share this post


Link to post
Share on other sites
What do you mean by 'stored'?
On disk, geometry tends to be stored for fast loading or, for big games, high entropy.
In memory, level data is usually stored in a GPU-friendly format (so it's often split into index and vertex buffers) with considerations for physics, which often involves storing an extra instance of simplified geometry.

Typically, a high-level abstraction format is employed to store levels on disk. For example, every static entity (e.g. tree, wall segment, chimney) may be stored as a mesh, with common static collections of these entities stored as an array of these primitives (e.g. house <-> a roof at position X, chimney at Y, four walls at Z1, Z12, Z3 Z4). A patch of level might then consist of a heightmap with arrays of such collections. Continuing in this way, we build up a level, by recycling in a way so that there is very little duplication. This means we can fit the game on smaller media and that it takes less time to haul it into memory at load-time, by keeping the CPU busy and the drive heads not.

When the data does get loaded, it is the job of the loading routine to expand the chunks in a recursive manner so that the entire level is finally made of buffers of vertices, so that we can simply point the GPU at some subset and have the whole thing render for us. Naturally, the entire level's geometry is far larger than the compressed form on disk, and it probably won't all fit in memory at once. This is where the engine is required to algorithmically page and evict level data, so that everything in visible range is present at any given time, with little enough superfluous data to prevent VRAM thrashing. Implementing this successfully is something of an art and it can make or break the feel and performance of the game.

While memory constraints are fairly rigid on disk and in the pipeline, RAM tends to be abundant and so it is commonplace to sacrifice some system memory to ease the load on the CPU. By this, I mean a game will often store a simplified copy of the level geometry so that collision detection has a smaller working set, for example. Also, a game will often partition its geometry into some structure, often a recursive one such as an octree, quadtree or binary-tree so that inter-entity tests need can be made local rather than global. This reduces the CPU's working set, allowing for a higher frame rate, in general.

Another boon of spatial partitioning is that it can ease the GPU's workload. By splitting space into chunks, if we can quickly determine if a chunk is visible or not, it becomes possible to trade in a little CPU time for a lot of GPU time.

The general term for a data structure responsible for partitioning of game entities, for performance purposes, is a scene graph.

So we have a variety of mechanisms by which we shift the workload from one machine to another, effectively spreading out our resources to achieve maximum performance. Exactly which of these techniques are necessary is highly dependent on the style of the game, and is largely determined as the production phase develops: through frequent profiling, the developer can find out which of his resources are in the highest demand, and take measures to redistribute the workload.

So to answer your question, I'm afraid there is a lot to learn, and nobody here knows all of it. There are certain techniques that are vital to almost any 3D game (batching, spatial partitioning) and others that are far more specialised. I suggest you take a look at GameDev's articles section. Most of the important topics are described there.

Admiral

Share this post


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

  • Advertisement