deformable terrain

Question

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?

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.