Cubic Chunks → Column Chunks

[cb341]

After some consideration, I have come to the realization that CubicChunks are probably not the best way forward for rsmc. I don't plan on generating vertically infinite terrain anyways.

Some ideas

Pros

• ColumnChunks lead to fewer meshes → fewer drawcalls → higher fps
• ColumnChunks buffers are more contiguous, which could yield better compression performance
• ColumnChunks allow speedup in TerrainGeneration as I can use a HeightMap before sampling Noise
• Potential for subchunks → skipping parts of chunks for storage, meshing
• Theoretically better greedy meshing potential
• Much easier handling of Gravity Blocks
• More control over terrain generation such as surface level
• Cheap lighting calculations
• Fewer ChunkManager keys
• Fewer synchronization tasks
• Fewer neighbors to keep track of → Simpler implementation of complex generation, such as structures in the future

Cons

• Coordinates are no longer symetrical (IVec3 → ChunkPosition, i32)
• No more vertically infinite terrain
• Potentially more booring caves
• Slower meshing
• Larger meshes
• Slower initial world load (as we need to stream more than just the "subchunk" the player is in)

[cb341]

We can no longer copy chunks.
Storing them on stack yields StackOverflow errors as the memory requirements are too large, hence the heap.

[cb341]

This aims to improve cache locality.
We usually iterate in order x,y,z.
This way z is the most frequently changing variable.

z,y,x order over x,y,z should improve performance.
I didn't look into it too deeply.

[cb341]

👍