Hi, glad to hear of your interest!
Zauber Paracelsus wrote:
1) There is a branch that includes a dual-contouring surface extractor. How ready is it for production use...
Actually this work was done by Matt so I can't really say how production-ready it is. But to my knowledge it is at an early stage and only tested on simple data. Also, some work will be needed to merge it with the develop branch as some refactoring has taken place.
Zauber Paracelsus wrote:
...and is it exposed through the Python bindings?
Probably not, and this is my fault. The SWIG bindings are often broken because I do some refactoring and don't get around to updating the bindings as we don't use them ourselves. Actually, PolyVox is now header-only so it's not quite clear to what extent the bindings make sense.
Zauber Paracelsus wrote:
Actually, how much work is being done on it? The most recent commit to the branch is from late February.
To my knowledge it is not being actively worked on, as Matt has been busy with the Cubiquity for Unreal integration recently.
Zauber Paracelsus wrote:
2) Does polyvox optimize the geometry of the generated meshes? If so, what kinds of optimizations does it perform. Does this include distance-based LOD?
I cannot answer this for the Dual Contouring extractor. For the cubic (Minecraft-style) mesh it does perform greedy-meshing, but for the Marching Cubes mesh no simplification is performed. In Cubiquity we build on top of PolyVox, and implement LOD by downsampling the volume data and extracting the mesh from that.
Zauber Paracelsus wrote:
3) Is there any limitation on the amount of materials that can be used on voxel terrain in polyvox? Or is it whatever limit you set in your code?
In general PolyVox is not aware of materials. The library is templatised and you can include whatever data you like in a voxel (material, color, etc). Whatever per-voxel data you have gets copied to the extracted mesh as per-vertex data. This is for Marching Cubes, I think Dual Contouring is expected to work in a similar way.