Project development

Whilst the project was originally intended as a simple addon based on Blenders exposed Python API, that plan had to be scrapped early on as Blender does not offer support for creating custom modifiers using their addon API. As a result, the C / C++ source code had to be modified and the program recompiled.
Sadly, Blender's source code documentation was outdated, and in some parts non-existent, leading to a lot of reverse-engineering and traversing poorly documented code to understand how the program worked.
Due to this, writing a custom modifier in Blender version 3.2 proved to be a rather difficult task. The source code of the custom Blender build can be found at the bottom of this page and should be documented enough to explain the workings of the various structures and allow people to write their own modifiers easier.
One of the main changes that needed to be made was adding the modifier information and data to Blender's DNA and RNA components. These are used to store the program's runtime memory and project on the disk. Blender uses build programs called "makesdna" and "makesrna", which generate code out of strictly declared memory structures in the "source/blender/makesdna/DNA_modifier_types.h" and "source/blender/makesrna/intern/rna_modifier.c" files. More information on this can be found in an outdated blog post on creating custom modifiers for Blender and in their developer documentation.
In order to remesh a model using the Marching Cubes algorithm, we first need to voxelise the mesh and create a scalar field filled with density values. After a bit of research I discovered that Blender uses a similar technique to convert Meshes into Volumes, and already provides an implementation of an algorithm to convert a mesh into a scalar field, stored using OpenVDB's FloatGrid structure. Once again, due to poor documentation of the Blender source code, I had to reverse-engineer the provided algorithm to understand why the values in the resulting grid ranged from 0 to a seemingly random maxima.

Due to Blender's capabilities to be used as a 3D modelling tool and the support of N-Gons (polygons with n-sides) Blender does not use a simple triangle strip to store meshes in memory. Whilst the OpenGL-based rendering backend ends up converting these structures back into a simple triangle strip to send to the GPU, the mesh data itself needs to be stored in what Blender calls a BMesh. BMeshes are structures that store not only faces, loops, edges and vertices, but also much more metadata about the mesh, such as connectivity cycles that store persistent adjacency information. The same applies to mesh, or faceloops. In order to allow for N-Gons, a face is defined by a loop of vertices of variable length in which each index points towards the subsequent vertex in the face. Because the Marching Cubes algorithm only produces triangles, we can assume our loop length to be 3 for each face and easily fill in the loops afterwards. The implementation of this can be seen in the Marching Cubes algorithm. The modifier structure itself is defined in the "/source/blender/modifiers/intern/MOD_MCube.c" file. All submethods and functions called are documented and placed in the according, best-fitting project source code files to avoid breaking the project's code structure.