Voxel Project: Marching Cubes

Before We Get Started...

Empty gaps where there should be blocks

There was an issue with the grid where blocks placed on the outer edges of the grids weren't rendering, resulting in holes where blocks are placed. This was pretty easy to fix, since I just had to restrict block placement so that the outer edges are off-limits. I also added a simple camera movement script to make interacting with the grid easier. Neat!

Time to March

First, in order to add more detail to the voxels, the voxels need to store more information. Initially I used a matrix of bytes to store the presence of voxels, but now that there can be different types of voxels, I swapped to an enum matrix instead.

What I found very quickly is that there are a lot of different potential shapes when factoring in rotations and flipped versions, even with just basic corners and slopes. In fact, even when only factoring in directly adjacent voxels, each voxel could have up to 64 different shapes! (though in my case I only have 22 shapes) Even with the few shapes I added, the grid is already looking more defined.

In addition, rendering the shapes became a lot more complex as well; where as before, I simply had to check if neighbouring faces were occupied, now depending on what block is neighbouring the current voxel different triangles have to be rendered.

This is what happens if you don't.

As a result, we now have a much more defined voxel grid, rather than the minecraft-esque one we had last week.

This is what happens if you do.

Up Next...

Even this early into this project, the grid is starting to get a bit performance intensive, and there are a lot of spots where we could improve on. In particular, the mesh collider for the grid has much more triangles than needed, being an exact copy of the mesh itself. Next week, I want to focus on reducing the poly count of the grid's collider, as well as cut down on some of the inefficient aspects of my code.

See the code

Next Up: Optimize Collider & Voxel Mesh Count