In early 2012, I implemented Eric Lengyel’s Transvoxel Algorithm in C# for Microsoft’s XNA game development framework. I wanted to build voxel-based terrain that could render massive worlds efficiently, but kept hitting the same problem: visible cracks and seams where different levels of detail met.
The Problem I Was Trying to Solve#
When I started rendering large voxel worlds, I quickly realized I needed Level of Detail (LOD) techniques to maintain acceptable frame rates. My approach was straightforward: render distant terrain with larger voxels (lower detail) and nearby terrain with smaller voxels (higher detail). The framerate improved dramatically, but the visual result was terrible.
The issue became obvious as soon as I moved the camera. Everywhere a high-detail chunk bordered a low-detail chunk, I saw visible gaps - cracks in the terrain where vertices didn’t align. My initial implementation used a standard marching cubes algorithm, which simply wasn’t designed to handle mismatched LOD boundaries. I needed a better solution.
Discovering the Transvoxel Algorithm#
After researching LOD techniques for voxel terrain, I found Eric Lengyel’s Transvoxel Algorithm. Eric had published detailed documentation on Terathon Software’s website, including the complete transition cell tables and mathematical foundations. This was exactly what I needed.
His approach: instead of forcing standard marching cubes to work across LOD boundaries, use special transition cells designed specifically for boundaries between different detail levels. The transition cells use a modified lookup table that accounts for vertex position mismatches, creating a crack-free mesh that bridges detail levels.
The properties convinced me to implement it:
- Watertight meshes: No cracks or gaps between LOD levels
- Smooth transitions: Visually pleasing interpolation between detail levels
- Performance: Lookup-table approach similar to marching cubes, no massive performance hit
- Consistency: Same triangulation on shared edges regardless of which chunk generated them
The theory made sense. Now I had to implement it in C#.
Building the Implementation#
I started with the core surface extraction, porting Lengyel’s transition cell tables. The tables were straightforward - just large lookup arrays - but getting the coordinate systems right took longer than expected. Every vertex had to align perfectly, or I’d end up with gaps worse than before.
Managing the volume data efficiently was the next challenge. Voxel terrain eats memory, so I built an octree-based storage system. Nodes deeper in the tree represented higher detail, while parent nodes stored lower detail versions. This gave me automatic LOD management. Making the volume data structures generic let me experiment with different density field types without rewriting the core algorithm.
The final piece was integrating with XNA’s graphics pipeline - converting the extracted surface data into vertex and index buffers that XNA could render efficiently.
Oggs91 joined the project early on. His work refining the octree structure and volume storage systems made a real difference, particularly his insights into memory layout and cache efficiency.
Iteration and Refinement#
My initial implementation in February 2012 focused on getting the transition cells working correctly. Weeks of debugging vertex alignment issues followed. The breakthrough came when I finally saw terrain with no cracks - exactly what I’d been trying to achieve.
Performance was another matter. By August, the initial octree structure and volume storage weren’t efficient enough for large worlds. I experimented with alternative storage strategies, trying to reduce memory usage without killing access speed. Making the octree generic helped - I could try different data types for density values and find the right balance between precision and memory footprint.
Years later, in July 2019, I revisited the project. XNA was no longer developed by Microsoft, but MonoGame had become a mature cross-platform alternative. I updated the code for MonoGame and Visual Studio 2019 to keep it useful for modern C# game developers.
What I Learned#
Several challenges surprised me:
Coordinate Systems: I spent way too long debugging vertex ordering issues. Getting normals to face the right direction across boundaries was tricky. Creating debug visualizations that showed vertex ordering explicitly finally made the problems obvious.
Memory Management: Voxel terrain consumed memory faster than expected. The octree helped, but I was constantly balancing memory usage against access performance. Cache-friendly data structures made a bigger difference than algorithmic improvements - a lesson that applies to many performance problems.
Mesh Generation Performance: Real-time terrain modification meant mesh generation couldn’t be a bottleneck. The lookup-table approach was already fast. Profiling revealed that memory allocation and buffer management were the real bottlenecks, not the algorithm itself.
Edge Cases: The transition cells introduced edge cases that didn’t exist in standard marching cubes. Extensive testing revealed bugs that only appeared in specific geometric configurations - neighboring chunks at different LOD levels created combinations I hadn’t anticipated.
Releasing the Code#
I released the project under the MIT license in 2019, making it freely available on GitHub for use in MonoGame, Unity, and other C# game engines. While XNA itself is no longer actively developed by Microsoft, MonoGame continues to thrive as a cross-platform alternative, and the implementation remains relevant for developers building voxel-based games and simulations in C#.
Where This Matters#
My original goal was procedural terrain generation - large-scale outdoor environments where you could see for miles without sacrificing detail up close. The technique applies to other domains too:
- Minecraft-style voxel games: Smooth terrain alongside cubic blocks needs crack-free LOD transitions
- Medical visualization: Rendering volumetric medical data at different detail levels
- Scientific simulation: Visualizing fluid dynamics, weather systems, or other volumetric phenomena
The result: truly massive voxel worlds that maintain visual quality up close and good performance at a distance.
Credits and Resources#
This implementation wouldn’t exist without Eric Lengyel’s foundational work on the Transvoxel Algorithm. His detailed documentation and transition cell tables made implementing this complex algorithm possible. The original algorithm and documentation are available at Terathon Software.
Additional resources:
Thanks to Oggs91 for his contributions to the octree structure and volume storage optimizations.
Editor’s Note (2025): This project was created in early 2012 for Microsoft XNA 4.0 and later updated for MonoGame in 2019. While XNA is no longer actively developed, the Transvoxel Algorithm implementation remains a useful reference for C# game developers working with voxel terrain systems. Eric Lengyel continues to develop advanced graphics technology at Terathon Software.