FOSS gamedev and creative worlds

Some block 16x16x16 nodes: content stone.

Another block 16x16x16 nodes: content stone /where/, dirt /where/, air /where/, etc.

Is that how is saved world? If this is true, can cleaning some block (setting it to all stone or all air) decrease size of map?

nomohakon wrote:Some block 16x16x16 nodes: content stone.

Another block 16x16x16 nodes: content stone /where/, dirt /where/, air /where/, etc.

Is that how is saved world? If this is true, can cleaning some block (setting it to all stone or all air) decrease size of map?

I think that if there is less material to render, than take up less space

Sorry, i did not understand what you mean.

Left one takes much less space and (i believe) time to render.

Is that right or its always saved as in right part?

Here is my understanding.

Regarding map size: The data for a 16x16x16 block is stored zlib-compressed. So if every node in the block is the same, this should be substantially compressed.

Regarding rendering complexity: this is basically proportional to the size of the mesh, which is (roughly) proportional to the surface area. The surface area is basically the number of transitions between solid and non-solid nodes (e.g., stone-to-air). Transitions between different solid nodes (e.g., stone-to-dirt) don't affect the mesh-size.

In summary, a block consisting of only stone would have small map size and low rendering complexity. A block with only solid nodes, like stone, dirt, sand, etc would have a bigger map size (because it probably doesn't compress that well) but still roughly the same low rendering complexity. A block with alternating stone and air nodes will have relatively small map size (the repeating pattern should still compress somewhat), but quite high rendering complexity (because of many transitions and therefore high surface-area.).

Sounds like lod realisation - cool