Chunk linking and block storage support

[Pilvinen]

Sometimes we have situations where we want to represent an area in a certain way without doing the changes to the world data block by block.

For example we might wish to create large craters which are identical in appearance. It would be inefficient to do these changes block by block, especially if the craters are large or numerous.

For such cases it would be useful to be able to take a node from the octree which contains the chunk we want to change and link that node to a new chunk which already exists elsewhere in a separate chunk storage which is not a part of the normal world data flow - or copy that data over the world data without running any checks.

There are some open questions. The answers depend on what we actually need, and what is a sensible approach. Currently I don't have all the answers to these questions, but I will present all the options and possibilities below that I can think of:

Some concepts and clarifications

• Chunks saved in the chunk storage do not have actual locations in the world by default. They are "in storage".
• Chunks in chunk storage are not actively in memory by default.
• Select data in chunk storage can be kept synchronized with all the clients for fast retrieval. This can be revealing and should be used with some thoughtfulness. It can also be very useful in cases where a lot of identical data needs to be displayed. Instead of sending the data over the network chunk by chunk it can be sent over once and used often.

RW toggle Do we want to have read only data on low level? Enable/disable writing to any part of world data or chunk storage.

Restore Simple copy operation which reads data from the chunk storage and overwrites any and all data stored in the target chunk.

Swap This is a link swap operation where the actual chunk data does not move anywhere. There is data stored on chunk storage. There is data stored in world data. The data which was world data is now in chunk storage. The data which was in chunk storage is now in world data. But we do not copy the data over, we just link and refer to it's new locations.

Link Data remains in the chunk storage and we link (refer) to it directly from the octree node. In case of write being enabled the changes get saved in the chunk storage. Reads also refer to the chunk storage. Any old world data gets wiped when linking.

Store Write selected world data to chunk storage. Any data in the targeted section of the chunk storage gets overwritten.

Hard swap This is an operation like the swap, but the actual data is read, stored in cache, and cross-written from world data to chunk storage and from chunk storage to world data (instead of just linking and referring to it).

Store changes (Not displayed in the chart above) Store changes (delta) with timestamp and other information like what caused the change. For the purposes of later having a possibility to do build tracking and rollbacks for world data.

[bensku]

Good ideas. Implementing them all is probably not trivial, but definitely possible.