Implement Marching Cubes as mesh extractor

[jclarkk]

Use MC by default

[tomgelu]

Do you have image comparison of the results between FlexiCubes and this marching cubes implementation ?

[jclarkk]

@tomgelu
It would be ineffective to compare a mesh extraction method by image, it would be best to run both flexicubes and marching cubes and then compare results in Blender. I've done so myself on 5 different assets and the object structure was identical.

[0lento]

I've done some raw undecimated mesh comparisons with this and while it's not 100% identical, I can't really judge if either flexicubes or this outputs nicer looking mesh. I'd say it's close enough and actual raw mesh face count is very close on both, in fact was identical on one test when I just used merge vertices import option on blender.

What's noteworthy about this though, is that in my brief testing, it's seems to use less VRAM to decode mesh with this than it does with flexicubes, so I'm merging this on my low-vram fork for now. Thanks for sharing this!

[jclarkk]

@0lento
Glad to hear it reduces VRAM consumption as I haven't tested that myself, the gsplat implementation should also help in that regard.

[gongminmin]

I have to change 2 places in EnhancedMarchingCubes.__call__ to make the vertex color correct.

1. colors = self._interpolate_colors(deformed_vertices, voxelgrid_colors) to colors = self._interpolate_colors(vertices, voxelgrid_colors) . The deformed_vertices is not the coordinate in cube frame.
2. return deformed_vertices, faces, deviation_loss, colors to return deformed_vertices, faces, deviation_loss, torch.sigmoid(colors). To align with Flexicubes, the colors need to be sigmoid() to go back to 0-1 space.

They affect vertex colors, which is hidden by the texture. So not easy to be seen.

And yes, I can confirm the VRAM consumption drops. It was 13GB with Flexicubes. Now it's 10.1GB, right below 12GB threshold.

[jclarkk]

@gongminmin
Added proposed changes, thanks for that.