I'll try to provide some context for the changes which are taking place. The idea is that voxels no longer have a fixed set of properties (density, material, etc) but instead have whatever the user decides they need for their particular application. Even primitive types can be used as voxels, which means they have no properties at all. So basically voxels can be any type and PolyVox algorithms (which are more than just the surface extractors) have no knowledge of the type on which they are operating.

However, some specific algorithms do have requirements about the nature of the data. For example, the Marching Cubes algorithm conceptually operates on density values (and the PolyVox implementation also uses the materials). Therefore a MarchingCubesController (such as the DefaultMarchingCubesController you found) takes responsibility for converting the underlying voxel type to a density which the MarchingCubesSurfaceExtractor can use.

The CubicSurfaceExtractorWithNormals is a little bit different... it stills knows nothing about the underlying type but it doesn't need to. It doesn't need the concept of densities and contains no calls to getMaterial(). Instead, the only requirement is that it needs to determine whether a quad should be placed between any two voxels. It does this by calling IsQuadNeeded(), and the default implemtation of IsQuadNeeded() does check the materials (but the CubicSurfaceExtractorWithNormals doesn't know this).

The idea is to increase flexibility and also allow some variation between the way the different algorithms work. An algorithm can require the presence of getDensity() and getMaterial() function if it makes sense for that algorithm (though it then won't with primitive types), or it could generalise it's requirements in the way that the CubicSurfaceExtractorWithNormals does with IsQuadNeeded().

Overall, the approach is becoming more similar to the way the STL works in C++. I still think that std::sort is a good example in the way that it uses a 'comparator' object to help it interpret the underlying data. It doesn't know anything about the types that it is sorting, just that the comparator can tell it which one is bigger.

In your particular case, we should consider what are the core concepts? Does it need to know about densities, or does it just need to know whether a voxel is solid? Does it need to know about materials (I guess so...)?

So as an example, you might decide that your extractor needs to take two function objects called 'IsSolid()' and 'ConvertToMaterial()', which are then used by your extractor to get the information it needs from the voxels. Alternatively you might decide to make these members of a 'PointExtractorController' class (which is what I did for Marching Cubes). Or instead, you might have a single user-privided function which returns an std::pair<bool, float> indicating whether a voxel is solid and what its material is.

There are some complex ideas here for a PolyVox developer, though I do think it makes it easier and more flexible for the user. I've also started writting documentation, so look at the latest DefaultMarchingCubesController and also the Changelog.txt in the root folder. Do ask if you have questions, but don't let it worry you too much as you can still use the getMaterial() and getDensity() functions for now if you want.

I implemented an extractor controller outlined above and changed the algorithm to handle transparent voxels. (Useful for instancing things such as grass for example, discussed in another thread).
The algorithm is delightfully simple actually.

Apart from proper testing, the surface point extractor seems to be fairly complete. I would appreciate some feedback on the code, it's on gitorious under the SurfacePointExtractor branch.

I will create a small demo in Panda3D testing instancing and the SurfacePointExtractor soonish to find any bugs/showcase it.

The files of interest is:
DefaultSurfacePointExtractorController.h
SurfacePointExtractor.h /.inl

Great stuff, this looks very promising.

As you say, I think the most important thing now is to try testing it in a real application. My main interest would be regarding the format of the output data and how you need to deal with rendering transparency, especially as we haven't dealt with transparancy in PolyVox before. Are we talking about 1-bit alpha (like you'd use for grass) or full alpha (like you'd use for water) here? For example, you probably need to to sort the transparent voxels from far to near? Perhaps presort for each main view direction? Do the transparent vs solid points need to be in seperate meshes so they can be drawn as seperate batches?

I think you'll find there are some challenges here so some research might be needed. I'll be interested in what you find, and we might need to take some of these things into consideration when redesigning the mesh class in the future.

There are also a couple of changes you could make to the code if you think they make sense. For example, rather than having 'isSolid' and 'isTransparent' perhaps you could have 'classifyVoxel' which would return an enum from {Empty, Solid (or Opaque?), Transparent}. That way a new implementation of the controller can't accidentally say that a voxel is both solid and transparent. But really I wouldn't worry about this too much at the moment, it's probably more important to test the functionality and the rendering.

Just a small update, I've been having issues with the geometry shader, I'm not sure wether it's the game engine(panda3d) or the the driver or my codes fault, and don't have access to nvidia hardware to test it out with different drivers. If I can't get it working soon I'll try it out with GamePlay.

I would like to aim for both (1 bit and opaque), I wasn't aware of the sorting problem before now. I have read a bit about it, but I'm unsure how to sort when using hardware instancing, will definitely need to research some more.
Regarding whether the transparent vs. solids has to be in seperate meshes (objects), yes actually everything that has a different mesh (Material?) will need to be separate. I just assumed this splitting will be done in user code, but it might be better to extract only a specific materials' points at a time, or the extractor returning an array of meshes (point lists) one for each material reducing user code needed.

Oh yes, enums will make it nicer, more extendible too, will make it harder for users who use the wrappers to use though (Not sure on python/swig support on enums). In regards with wrapping, I'm starting to wonder if wrapping the entire project vs. wrapping a simple C interface is worth it. It seems that C++ bindings are really hard to write, for both automated and manual wrappers, whereas C interfaces is much easier to work with. Will of course require people to know a little bit of C when they want to customize anything.
I tried the python CFFI library, amazingly easy to use.

Perhaps you could try running another aplicaion which uses geometry shaders? Some of the Ogre examples use them, otherwise you could just search for OpenGL geometry shader tutorials. This should at least let you work out whether they are supported properly by your card. Again, if you have Ogre installed you could try: http://www.ogre3d.org/forums/viewtopic. ... 3&start=25 Then you should be able to convert it to Panda3D


The sorting problem only affects full-range transparency, for 1-bit alpha there is no need to sort because the depth buffer can take care of deciding what is visible. For this reason 1-bit alpha is much easier and is what is used by Minecraft for windows, ladders, etc. If you just get this working then it will already be an achievement. But still you should start by worrying about completely solid blocks first... i.e. get you geometry shaders working as expected.

Full-range transparency would be fun though... it's also something which is on my mind for the CubicSurfaceExtractor.


The answer here is not entirely clear to me, but I think it depends how the user want to render the data. For example, if they always render a cube (regardless of the material) and just use the material to decide how to texture it then I think in this case all the points can stay in the same array. The material can be passed though to the GPU (similar to how the other extractors work) and used to look up into a texture atlas for example.

On the other hand, if the user wishes to draw a different mesh based on the material then I think they will need to split the array of points into seperate arrays based on the material. This is probably their problem rather than ours, but I think we could provide a utility function for this purpose. But again, I think we can come back to this once we have the basic rendering working.


Actually I wonder whether some parts of PolyVox even need to be in classes in the first place. For example, to use the cubic surface extractor you first have to create a CubicSurfaceExtractor object and then call it 'execute' function. But why not just replace this with a single function called 'extractCubicSurface'? I think that C++ (function overloading, templates, etc) is useful here but classes are not. On the other hand, some things (such as volumes) do make sense as classes. I think that in general we should take an STL-like approach where data structures are classes but algorithms are just functions.

Our mind map mentions 'Convert Raycast into function' as I was planning to use this as a test for this process, but if you want to try changing your algorithm into a regular function instead of a class then you are welcome to give it a go.