I'm currently working on a 3d sandbox mmo and would like to know what would be the best way to store the terrain of the world. I was thinking about making some kind of mesh, like the kind you would get from an obj file, that would define the whole world. I would have one for every type of terrain there is (a stone layer covered by a dirt layer and the stone layer could have "tunnels" of ore, each with it's own mesh defining the shape of it). I would then pass part of that mesh to the players depending on where they stand in the world.

I'dd like to allow the players to deform the terrain and dig holes and caves (like you would see in planet explorers or space engineers) in a persistent world so no need to generate it on the fly.

I've seen many post online talking about isosurface and even tho i searched far and wide, i couldn't find a clear definition of what that was or if it applied in my case. I just want to know if storing the terrain as a mesh would be the best approach. And if so, would it be best to have it based on a strict x,y,z integers or would it be possible to have it stored as floats for more diversity?

I intend to have a smooth terrain using marching cubes or dual contouring. can you give me your thoughts?

  • \$\begingroup\$ for storage you can you some geometry compression schemes, there were good presentations at siggraph 2014. creatis.insa-lyon.fr/~valette/pub/VCP09SGP.pdf liris.cnrs.fr/glavoue/travaux/conference/WEB3D2013.pdf \$\endgroup\$
    – v.oddou
    Commented Oct 1, 2015 at 1:46
  • \$\begingroup\$ but basically, they way i described is valid? have one mesh to represent every type of material my terrain is made of and return a fraction of it to the users and let the client render it with marching cubes, interpolation and etc? otherwise, i just can't visualize how to make a "world" and save it so that all player plays on the same maps and still be able to send a reasonable amount of data every few cycles. \$\endgroup\$ Commented Oct 1, 2015 at 2:51

1 Answer 1


I am going to go on a whim and say that you are using voxels, because you want to be able to dig holes and tunnels live. Storing a world whose state can forever change as a .obj would not be a good idea.

For your sanity, and your customer's sanity, you would be better off choosing a different format style.

First step: split the world up into chunks. If an area gets corrupted, you can just reload the chunks around it instead of the entire map.

Second step: writing to disk.

My suggestion would be to save information about the voxels themselves as a texture 1D, 2D, or 3D. You can reduce the bits for color information to reduce the size some. But you probably don't want to get rid of it all. You can then use the color parameters to store information about the world state.

(Roy Gee Biv = RGB colors) Example... For a 2D texture Roy can tell you the material in that location. Gee can tell you the depth. And Biv can store bit fields if needed.

For a 1D, Roy can tell you depth, Gee can tell you depth, Biv can tell you the X location, and Alpha can tell you the Y location.

Given the game is an MMO, it is expected that the servers will be up for a long time. It will not matter how quick it is to load an object, as long as it's efficient.

When the game saves, it just dumps each chunk into a texture somewhere on the disk as a backup. When it needs to revert back to a backup, it can load in the texture. So at this stage, you are re-reading cubes.

Your world is already capable of smoothing out geometry if it does. So you don't need to worry about the state of it's geometry. The game will simply rebuild it all once more in a couple of seconds.

The benefits would be that you don't have to make your own dang library or file format. There are also lossless compression algorithms for 2D textures as well.

The cons are that you might not be able to store information that is more than just the world's geometry. This could be a very big con... could be a very small con. But... there is no rule preventing you from loading in two files if this is the case. Which can be a nice feature.

  • \$\begingroup\$ I was using the term obj as an example of the structure of the vertices being saved server side. for the normals and texture and UV map, i was thinking about storing and computing it client side so i would only need to send a list of vertices and indices that make the general shape of the world. since every type of terrain will be stored independently, if a player stands on dirt and there is stone below that dirt, i only need to send the mesh for the "dirt" and "stone" with a bit header letting the client know what type of terrain it is, thus saving the need to send normals and texture coord. \$\endgroup\$ Commented Oct 1, 2015 at 3:28
  • 1
    \$\begingroup\$ I don't understand what's the advantage of (ab?)using a texture for this instead of just using a custom data structure. \$\endgroup\$
    – Philipp
    Commented Nov 30, 2015 at 9:53
  • 2
    \$\begingroup\$ Roy gee biv? What are you talking about. It's called Red Green Blue \$\endgroup\$
    – KaareZ
    Commented Jan 29, 2016 at 14:54
  • 1
    \$\begingroup\$ "Roy-G-Biv" is the colors of the rainbow. Red, Orange, Yellow, Green, Blue, Indigo, Violet. Of course, indigo was made up just so the acronym works. \$\endgroup\$ Commented Jan 29, 2016 at 15:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .