Caution: lots of gamedev talks ahead! :D

During the initial development, the game went through multiple implementations of the mesh generator that produces 3D models visible in the world. This post tries to go through every kind and describe their pros and cons.

Greedy mesher

Let’s start with the obviously popular algorithm: greedy meshing: the mesher goes through every voxel and keeps track of contiguous strips of same-kin voxels, and then merges their faces. The big benefit of that is the fact that your meshes have significantly less vertices, thus occupy a fraction of video memory compared to other methods.

Here’s a 2023 revision of Voxelius generating a chunk mesh using greedy algorithm:

However, the memory and performance gains are overshadowed by my decision to implement varying voxel textures. Since every voxel’s face textures can now be randomly chosen depending on the voxel’s position, greedy mesher became something of a burden to maintain…

Another big issue with the greedy algorithm is pixel-sized gaps that are very visible when rendering to a smaller framebuffer. You can see this “glitch” in effect on the screenshot below:

Naive mesher

This is the industry-standard way of generating cubic voxel meshes. Even Minecraft uses it to this day (the reasons for that are different: MC mainly uses it because it defines all the voxels as custom models and also uses a texture atlas compared to Voxelius’s array texture approach). Unlike greedy mesher, it doesn’t merge voxel faces together, instead generating one face per voxel per side.

The naive algorithm solves pixel gap and variations issues and also does it’s job in an almost constant time per chunk!

However, nothing is ideal and video memory usage of naive mesher is drastically worse than that of a greedy algorithm; however, I solved this issue by implementing an optimized rendering method for voxels (which is probably worth a different post)…

You can see the new mesher’s work in the screenshot below: