Hey!

I started with PolyVox not long time ago in the Unreal Engine 4 and it works pretty well so far.

However when using the marching cubes surface extractor (develop branch), I noticed extra faces when using marching cubes which also seem to have weird normals. Is this normal (even though it seems like these extra faces could be avoided?) or is this a bug?

Mhh, after changing some parts of my code, the extra faces are gone. I'll try to find out what caused them.

This is a valid output, it completely depends what the underlying voxel data looks like. Are you using integers or floats? Perhaps your threshold is off by a small amount?

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.

Indeed, PolyVox uses a simple central-differencing approach to normal calculation which can fail for certain voxel configurations such as a checkerboard. I can't say I've really had a problem with it myself, but computing vertex normals as the average of face normals is a pretty standard approach if you want to replace them.



Actually I thought Paul Bourke's implementation (the original basic for PolyVox) had included the fix for ambiguous cases, though I may have been mistaken. They have never caused me any problems though I agree there are many more advanced algorithms available now - Marching Cubes is now 30 years old!