I've been a little quiet recently, but finally there is a new feature to show. Those of you who have been following this bug report will have seen it already, but it seemed important enough to have it's own thread.

The CubicSurfaceExtractor has been significantly optimised and now supports built in decimation of the surface it generates. Previously, the CubicSurfaceExtractor would generate way more triangles than necessary, and these could then be removed using the MeshDecimator class. However, this was proving to be slow and error prone.

The new CubicSurfacExtractor is faster than the previous one (roughly twice as fast), generates a lot less triangles, and is much more robust. As far as I can tell it is better in every way. Here are some before and after images:





As a result of this I intend to deprecate the use of the MeshDecimator for cubic meshes as I don't believe it is useful anymore. It will remain functional for smooth meshes though as it works better for these and also we don't yet have an alternative solution.

Awesome!

_________________
irc://irc.freenode.net/#polyvox

WOW! You DA MAN!

Thanks guys

I also should have mentioned that it's possible to turn off the decimation if you wish, via a constructor parameter. I think the only reason you might want to do this is if you are doing some kind of per-vertex computations (e.g per-vertex lighting).

I don't think there is any point still generating an undecimated version first, and then replacing it with a decimated version in a background thread, because the decimation now only takes about 20% of the total extraction time.

If only we had the same improvement to the smooth meshes

I do think it's possible to do something similar, in that the smooth SurfaceExtractor could have decimation built in. This should give a perfomance improvment like it did for the cubic meshes (though not as dramatic, as decimating smooth meshes is more complex), but overall I still think it's worth persuing the approach of down sampling the volume first.