Hey there.

Lately I've been playing with polyvox, and decided to try out Dual Contouring ( I merged it from it's branch with master ).

As the controller I decided to try and use DefaultMarchingCubes controller. It didn't work and I had to make the "get" functions be constant in the mentioned controller class. That solved it.

Then, I've found out that dual contouring forces voxel type to be a double (?), so I've tried to feed it with SimpleVolume<double>, but no dice - I couldn't get any vertices / indices generated, even after filling the volume with data ( I've set the doubles to either 10 thousand, 50 thousand or 1 ). I'm not really sure how do thresholds and density work together, but I just wanted a cube.

My question is - does dual contouring really work with doubles only? What about materials, then? (I couldn't supply it with MaterialDensityPair44, as it required the density to be signed, so I tried to feed it with MaterialDensityPair<int16_t,8,8>, but I was getting some other kinds of errors. Not really fixable to me )

If yes, what data (double values) do I give to it so that it actually generates something? (what density)

And lastly, is it possible to include material id along density value with dual contouring?

Sorry that it's so many questions about an under development feature, but I'd really like to try it.

Well, this is because your density.

If all your density is greater than the threshold, it will not generate any vertices since everything is a solid, and same for everything below the threshold.

Density is what makes up a marching cubes/dual contouring mesh.

If the density is greater than the threshold it means that it's solid, but if it's less than the threshold it means that it's air.

For a model to be generated you need a mixture between air and solids.

Next off I'm sure that a float would work as a density value. Note that density is NOT the same as a material. Density shapes the model while materials would contain the texture info and color info.

The Dual Contouring stuff was actually done by Matt, and I know he's away at the moment so I'm not sure you'll get an answer. But I'll fill in the best I can.

To my knowledge the dual contouring extractor does work, but it's not entirely clear how it should behave or what kind of data it should operate on. PolyVox is a library for storing/processing volume data, but the input to dual contouring actually requires additional information in the form of normal vectors at intersection points. In this sense it's not 'true' volume data, and these intersection points and normal vectors are kind of an encoding of the mesh in their own right.

If you look at other dual contouring engines such as Voxel Farm or Upvoid they don't really seem to store much in the way of voxel data, but instead rely on procedural generation. Noise function and CSG operations are used to define the scene, which is then voxelized on demand for input to the dual contouring algorithm.

I'm being a bit vague and hand-wavy here, but the point is that it wasn't clear to us that it really makes sense to manually build a volume by calling SetVoxel() on each voxel and then run Dual Contouring on the result, and it seems that quite advanced algorithms were needed to manipulate the volume data in meaningful ways. Such procedural generation and algorithms would be outside the scope of PolyVox so it wasn't clear if Dual Contouring would be a useful addition (people wouldn't now how to use it).

That said, we did have some promising ideas. It did seem that the DC algorithm would make it quite easy to combine the benefits of the marching cubes extractor (smooth terrain) with the cubic extractor (blocks), while still having a simple interface. So it's still on the cards and if Matt wants to develop it further then great, but it's not quite clear at the moment.