When dealing with a voxel world the number of blocks visible at one time grows quickly as it depends on volume which grows as n^3. Looking at MineCraft again for some examples: the far distance has a view diameter of 512 blocks. If we take the volume of blocks in a square (of course) around the player this is 512x512x128 = 33.5 million blocks. With a few bytes of data per block we’re already over 100MB of block data alone.
If our world is going to have a larger view distance as well as a deeper world we can very quickly get into untenable requirements. For example, a 1024x1024x1024 block world will require several GB to hold the block data. This may be fine on a desktop with +8 GB of RAM running a 64 bit OS but definitely not fine on a 5 year old laptop with only ~1 GB. Part of this is simply choosing a minimum requirement for the system although this is somewhat tricky: both too high and too low requirements are not good for different reasons.
So is there hope for a voxel game world with a significantly larger view distance? I think there are several possibilities worth exploring in more detail:
- Detail Setting — Just like in MineCraft and most other games we can have a “View Distance” slider to accommodate both high and low end systems.
- Chunk Paging — Blocks far from the player are unlikely to change so they are only needed to be loaded once when creating the chunk mesh and then discarded.
- LOD (Level of Detail) System — This is far from a new concept and the basic principle is that objects far from the player can be rendered in much less detail which permits the game’s render distance to be larger. Exactly how well this would work in a voxel world is an open question at the moment.
- Octrees — The usual answer for more efficient partitioning of a 3D world is to use octrees, essentially a binary partitioning of a 3D space. This is an undoubtedly poor explanation but that is as much as I understand at the moment. Combined with an LOD system it does appear to have some immediate benefits in reducing the potential storage size. For example, consider an “empty” chunk 32x32x32 blocks in size. In the naive approach this would take at least 32kb to store but in an octree design it would be just a few bytes.
If we go back to our imaginary 1024 block cube world with an arbitrary LOD system with the following detail reductions:
- >128 block Range = x2 reduction
- >192 block Radius = x4
- >256 block Radius = x8
- >320 block Radius = x16 reduction
This turns our multi-GB storage requirement into just 100MB. Adding an octree system on top of that may decrease the size even further.