David, The weird faces have indeed wrong normals in current Dev Branch, as they do in 0.3.1 as well.

Long time ago, I had a Checkers Voxel Data which I used to test most available Marching Cubes implementations. ALL of these implementation that used QEFs or Gradient-based normal calculations used to have some form of null normals even through that kind of normals were looking far more good for lighting than average-smooth ones.

In Crafterria I used following approach: After PolyVox Marching Cubes did its output, I reiterate all trianfles and IF a triangle have null normals, I generate them from the averaged normals of all vertices with same position plus the triangle plane normal, so we get it fixed. This was working good, however, within time, I removed Polyvox from the game and wrote marching cubes myself using alternate lookup tables. I used the classic smoothing algorithm that I average vertex normals and it was working quite good.

Marching cubes is indeed easy as cake, If you (OP) manage to understand it you can understand it have flaws as well

For example, there is ambigous case in its original mesh set definition in by Paul Bourke. There is an implementation of Marching Cubes that resolves these cases, and it's called

**Extended Marching Cubes**. If you can invest a week or two to implement it you will benefit.

If you are making an open-world game, Marching Cubes will not help you that much because of LOD Issues. And any

**primal** method will be a waste, too. Go read about

**Dual Marching Cubes**.

And if you want to have smooth and hard shapes,

**Dual Contouring** is your friend however the algorithm is enormously heavy for big open-world games even today.