Hi all, with the first release of Cubiquity finally out of the door I'm now going to get back to PolyVox for a few weeks. Cubiquity is providing a great use-case to see what needs to change in PolyVox, and it's time to apply what we've learned. Many of these changes will break backwards compatibility so I'll use this thread to discuss what is changing and why.

Also, please note that there will be quite some disruption with class/function names changing, etc. You might want to hold off updating if you don't want to endure this instability. But we'll try and keep the examples compiling so you have something to work from.

The list below is just an initial taster - I'll keep posting here as other things change. Better volume and multi-threading is still planned but the refactoring below will happen first.

CubicSurfaceExtractorWithNormals is gone
This class was always a temporary measure as it generally makes more sense to compute the 'cubic' mesh normals in the fragment shader rather than having them stored per-vertex. This lets you perform flat-shading without storing any normals at all, which also avoids duplicating vertices on cube corners. The only reason we hadn't done this previously is that our examples didn't use shaders, but Matt has recently fixed that (at least for the example which matters).

CubicSurfaceExtractor does still exist though it is now a free-function (see next point). You should use this instead of CubicSurfaceExtractorWithNormals and compute the normals in the fragment shader.

Unclassing surface extractors.
Previously all PolyVox surface extractors were classes, e.g. MarchingCubesSurfaceExtractor and CubicSurfaceExtractor, but these have been replaced by free functions called 'extractCubicMesh()' and 'extractMarchingCubesMesh()'. There was no need for them to be classes, and having free functions makes the code much simpler especially when combined with C+11 'auto' keyword. The example code used to look like this:



But now it is:



Note that the code is shorter, and more importantly you don't need to specify any types. The voxel type can be inferred from the function parameters (in C++ this is not possible with classes) and the complex return type is obtained through auto.

Currently the free functions are actually just wrappers around the classes, but that will probably change in the future.

Vertex types are now templatised on VoxelType
PolyVox used to represent it's vertices with the awkwardly-named 'PositionMaterial' and 'PositionMaterialNormal' classes. These are now gone and replaced with new 'CubicVertex' and 'MarchingCubesVertex' classes. More importantly, the new classes are templatised on the voxel type, though the new use of the 'auto' keyword (as mentioned above) should limit the complexity which comes from this.

Users can store essentially any data they wish with a voxel, and so previously it was not clear how the 'material' should be represented, or even if it was present at all. Many users use an integer ID to represent a material, but at east on older GPU hardware it's only possible to pass floats as vertex attributes. Also, how should such material IDs be interpolated? It was all a bit messy.

The new system templatises the vertex types on the voxel type. So if you have a volume of floats then the MarchingCubesVertex will contain a position, normal, and a float. If you have a more complex voxel type then the MarchingCubesVertex will contain a position, a normal, and your more complex type. Note that you still need to define how you types will be interpolated because Marching Cubes vertices will always end up between particular voxel positions.

What you actually do with the voxel type in your vertex is entirely up to you. You can pass all or part of it to your shader, or cast the type to something different as you wish. PolyVox just takes care of pulling the voxel values out of the volume, interpolating them, and putting them in the mesh.

I hope that in the end, all the examples will work. Also, if the documentation is updated, I will be very happy.

Q1: What happens with isQuadNeeded & MarchingCubesController?
Q2: What is the exact type of mesh variable?

Will new surface extractors be added?

Me too



There are versions of the functions which take these as an additional last parameter, so they should continue to work. However, I am wondering how useful these really are, and whether the current system is more flexible and complex than it need to be.

For example, if you create a custom voxel type then you can define a DefaultMarchingCubesController to specify how the voxel type is interpolated (blended). You can also specify futher MarchingCubesControllers for your voxel type and pass one of these as a parameter to the surface extractor. But is it really useful to define multiple interpolation approaches in this way? Or are we complicating the code for no reason? If anybody has a case for why multiple MarchingCubesControllers are useful then I'd be interested to hear it.



In the example above the type of mesh is



I didn't show the construction of the volume, so I can't say what VoxelType is. The joy of auto is that you shouln't need to worry about it (much).

I can imagine we might add typedefs for these, e.g. 'CubicMesh<VoxelType>'.



Matt has been working on Dual Contouring on a separate branch, but I don't know what the status of that is.

Hi. IsQuadNeeded and custom MarchingCubesController are cruical to me. I have single voxel type that, in single voxel, contains either smooth terrain feature, Cubic terrain block, CUSTOM model block or liquid feature. Then I setup states and run the smooth extractor, cubic extractor and custom mesh extractor on this volume, so these features are the key in my case. I ended up with complicated structure that returns materials and densisies based on the game state / extractors state.

When I export only liquid marching cubes meshes, i set a state so the Marching Cubes controller returns densities only for voxels that are marked as liquids, then I setup this state and re-run the extractor, getting only the terrain meshes. Then I run a cubic extractor on this same volume that gets meshes only on blocks that are markes as cubic and so on. This is very good feature that I don't want to miss. (and you can't even be aware how powerful this feature is )

In short, every controller extracts only its set from the voxel field - be it liquid, smooth, cubic or even entity spawner

Ok, that's no problem, we shall leave the IsQuadNeeded and MarchingCubesController intact. It would be great if you can check that they still work with the free functions we have added.

However, I think the names 'MaterialType' and 'material' no longer manke sense in terms of the marching cubes extractor. Perhaps it should be 'InterpolatedDataType' and 'interpolatedData', to indicate that the vertex data is an interpolated version of the voxel data. Actually 'InterpolatedDataType' could be the same as 'VoxelType' (in my use-case), or it could be simpler (as in your use-cases).

Anyway, keep an eye on our changes and we'll try not to break anything for you

In fact I am not planning to update right now, I am scared that I may need to rewrite all my polyvox stuff from scratch.

Not from scratch, but there will be some changes needed so I understand that you don't want to update. We have the unit tests anyway so we can make sure the MarchingCubesController still works (I think we also have some ideas of how we want to use it ourselves).

There is a probability that I MAY need to rewrite my engine from scratch, because current design is not so optimized even if it already works flawlessly.

In this case I will update and I hope that I will be able to use single voxel type and different controllers to extract only these parts of it that need it, bacause I Don't want separate layers for terrain, liquids and blocks, (because these are ram overhead).

I'd prefer single layer of custom voxel type (like the SVT type from my other posts)

My voxel type needs to handle:

Marching Cubes: all terrain, all liquids
Cubic: Some building blocks
Custom: model-based voxels - spawning models based on their material type and surrounding voxels
Custom: Spawning common game entities from voxel data.

In addition:
Minecraft-styled Region -> Chunk -> ChunkSection design.
This time I will use Volume-per-region (and not volume per chunk as before)
And chunk sections will be small - probably 32x32x32 or 16x16x16.
We'll have too much meshes then but editing should be fast.

Implications with voxel data overlapping (2 voxels) and the chunk manager will now only need to be applied at the region borders. File on disk will store entire region.
Still, surface extractors will run in different threads on single RawVolume in a way that 2 chunks next to each other will ALWAYS be schedulled on single thread (no races). I already tested this, on LargeVolume it may crash, on RawVolume it's stable.
Chunk Section updates will be faster because of small chunk size, so we will rarely need to run it on more than one chunk or in very different threads.
and the chunk manager's setVoxelAt will have few border cases in which it will mark neighbour chunks and sections as dirty.

The implication of the new design will be the logic that considers a chunk region locked, but I am sure that this design may have performance benefit from the side if dynamically EDITING the terrain. More threads must be able to read the voxel data, and even write to the data at the same time, unless they try to R/W regions that can be raced (e.g. neighbourhood regions).

With current implementation that involves volume per chunk, the updating takes too much time and if I introduce chunk sections to this design, it won't be so easy to maintain, but this is the idea.

So I hope that if I decide to rewrite I will be able to achieve my task with single Voxel Type and custom controllers

Interesting topic to follow. If I may add to the discussion, I've been "working around" the usage of CubicSurfaceExtractor myself.

I'm using PolyVox in combination with Ogre. This works great once you get it working. However, I do have some ideas to improve the portability and/or usability of the SurfaceExtractor classes.

I use a ManualObject from Ogre, which basically allows me to draw all triangles "manually" extracted by the SurfaceExtractor. Here's the problem: Each draw call in the ManualObject accepts a single material. Therefore, the results obtained from the SurfaceExtractor have to be split on material. I managed to write an algorithm that does this in O(2n) time, where n is the number of vertices/indexes, but can likely be improved.

Secondly, on my Minecraft-like terrain, removing a block causes me to re-extract the mesh for the complete chunk. Then, having the new mesh, I can update the material that was removed, including any possible neighboring materials.

So basically I would like the SurfaceExtractor to have a parameter which material needs to be (re)extracted. Sadly I have no idea how the SurfaceExtractor actually works internally (I should probably look into it), so I also do not know if this is even possible.

... And thirdly, one Ogre material may have up to ~16 Texture units. Check my current code at following SVN:

https://sourceforge.net/p/kitten-platfo ... ree/trunk/

I am making material-per-chunk.

To compile this you NEED Qt Creator.

But there is build already in game-wd so you don't need to compile anything to run the demo on Windows.