Voxels, what’s not to love?!?

About 2 years ago I thought I would take a dive into creating a Voxel engine.  Well… engine is a loose term I suppose as I would be building such a thing on top of an existing engine.  A more apt description would probably be: About 2 years ago I thought I would take a stab at learning about voxel rendering and if my projects could benefit from such things.

Going in to the voxel fantasy with the inspiration of youtube videos was difficult as I had no idea where to begin.  Eventually I put the exploration onto the back burner as I had other areas of interest to develop for first and foremost.  It wasn’t until a recent game development meetup where I saw someone’s voxel engine that they had been working on for the last 3 years inspired me to revisit my former desires with voxels.

Over the previous 2 weeks I have created a voxel data structure, a chunk data structure, and found a way to successfully save the data to a file without all the raw overhead of writing out the entire voxel matrix.  In developing a voxel system, it quickly becomes apparent that I wanted to store the voxel data rather than simply rely on a perlin noise generator to procedurally generate my data every time.  The inspiration came when researching how other people have attempted to solve the problem.  In an article (which I cannot find the link to at the moment) that described a format which was merely a compressed [zip] file which contained horizontal slices of the voxel map as 2D images.  Although it never previously occurred to me that a voxel map was simply a 3D representation of the same 2-dimensional data, this got me to thinking.  All the work of image compression was done, and has been used in computing for decades.  I could merely store each vertical slice of the voxel map as a png, utilizing the lossless compression, and sprinkle in some meta data like width, height, and depth, for the loader to make sense of the data.  This also lead me down the thought process of scaling voxel maps [chunks] for level-of-detail purposes.  I could simply run each slice plane (starting with x, then maybe z, and following it up with y) through an image resizer.  Although it would probably be more efficient to write my own resizer that takes 3 dimensions into account rather than iterating over the slice axis 3 times, each time writing each slice out to an image, doing the resize, reading it back, and continuing the loop.  I figure that a pass through each axis doing a direct calculation might be optimal as opposed to adding an extra layer to traverse through.

Next steps are to create a Monobehaviour that allows me to pick images and create a chunk (of any scale) from that.  After that, I’ll work on resizing and file saving.  My goal is to create a planetary body and have it scale as the camera moves closer to it.  This would require that chunks can be divided into sub chunks, on the fly, and more detailed chunks be loaded in at run-time.