I'm slowly hacking away on this and I think I will need to break some functionality for a few releases.

Basically, I don't think it makes sense for the CubicSurfaceExtractors to have any concept of density. I think they should only work on materials. However, currently they do use densities and a threshold to decide which voxels are solid. What actually happens is that Material voxels provide a 'fake' getDensity() function which returns a high or low density based on whether or not the material is zero.

I will pull out these fake getDensity() function from the Material class, and the CubicSurfaceExtractors will only read the material and compare it to zero directly. However, the catch is that a user could have implemented their own voxel class with a fake 'getDensity()' function which does something diffrent than my own. I.e. they might have decided that materials 0, 5, and 17 all represented empty space.

I don't think anyone will have done this, but if they have that functionality will be broken (as the comparison to zero is now hard coded in the CubicSurfaceExtractor). It will be restored in a later release when I work on the surface extractors and provide some kind of callback mechanism to decide which voxels are solid. This will also be useful for transparency.

Yes, I was going to ask how this affects transparency since it's something we've been thinking about for a while. I guess for transparency the simplest way is to extract a separate mesh from a separate volume but it would be neater to be able to extract multiple meshes from the same volume, each extractor having custom properties for material types to ignore (i.e. treat as empty space). Just something to bear in mind when developing this stuff.

_________________
Matt Williams
Linux/CMake guy

Yeah, I may use a callback for this but I am concerned about peformance implications. Callbacks can be pretty slow when called millions of times. I might look at some kind of 'compile time callback' or maybe a lookup table which says, for any pair of materials, whether a quad should be generated. But I haven't got to this yet so I can't say for sure.

I think there are so many different uses, that you can't decide on one method of deciding when to create a surface.
Maybe you should do it like you did it with the Volumes... same interface, but different implementations.
Like keep the Material<> that makes everything but 0 solid, but create other Materials, some with callbacks, some with tables...

Ok, I'm now thinking of a more radical change. Instead of having member functions (getDensity(), getMeterial(), etc), how about those functions get moved outside the type. We could have free functions which can then be applied to primitive types and user defined ones.

The concept of 'densities' arose because this is what the Marching Cubes algorithm is based on, but it doesn't make sense in other algorithms. The CubicExtractor doesn't need it, for example. And the copying/resampling functions don't need to care (usually) what the voxel data represents - just that it can be copied and interpolated.

The various volume classes can already hold primitive and user defined types (as well as Material and Density types) and this can sometimes be useful. I think it should be possible to allow the Marching Cubes algoithm to execute on a volume of floats/ints rather than forcing the use to provide a class with a 'getDensity()' method.

Of course, the marching cubes extractor does still need to work on densities, and it needs to be able to get a density from the underlying data type. But this is possible by providing free functions. Within the algorithm , it would no longer call:



but instead:



PolyVox would include 'asDensity()' functions for all the primitive types, and actually this concept can still work with the Density/Material classes because asDensity() could just call through to 'getDensity()' for that type.

Looking at the CubicSurfaceExtractor, we could have something similar e.g. 'asMaterial()'. Better still, we can realise that the CubicSurfaceExtractor doesn't actually care about materials - all it really needs to know is whether a given pair of voxels need a quad to be generated between them. So internally it could call something like:



where 'isQuadNeeded()' is a free function in the same way as 'asDensity()'. Again, PolyVox would provide a version of this function for built in types, and users could provide their own version for their own types. This also provides a natural way of handling transparency for the CubicSurfaceExtractor without having to deal with callback functions (which I believe are slow when called millions of times).

So what are the drawbacks? Well, if I am going to provide implementations of asDensity(), isQuadNeeded(), etc for the built in types then the user will not be able to override these. My version of isQuadNeeded(int, int) will probably still use the comparison to zero (just solid/empty voxels and no transparancy). If the user provided their own isQuadNeeded(int, int) function then it would conflict with mine (compile error) rather than replacing it. Functions can only be overloaded based on their parameter types, so if you want a custom 'isQuadNeeded()' function you would also need to define a new voxel type. This could just be a wrapper around a int though.

I may be able to provide default implementations of these funtions via template functions, and then users could override then via specialization... but I'm not really sure about this yet. I'll have to see how it goes.

Any thoughts?

I like the idea, it looks much more refined than the previous ones to me.

I do not think there is a Problem with overloading.
A uint8_t volume cannot have any logic but a hardcoded one attached to it.
I'm not even sure it makes sense to have a volume of a raw type for extraction.

If you provide Material8, then the isQuadNeeded() function will simply check for borders from 0 to x or x to zero.
And Density8 would handle it differently... but both are internally uint8_t.

If someone wants a Material8 with different behavior, they can just clone it, rename it and create the isQuadNeeded() function. But that's already required right now, so no change there.

The only issue I see is when someone wants a Material8 volume extracted by the SurfaceExtractor, since the Density functions it requires do not know anything about the Materials that are alongside each other. But that's a general SurfaceExtractor issue (or not an issue, just not the purpose of it).

Yes, that is correct. It won't be hard to create custom voxel types. If I still provide Material8/Density8 it will be mostly for backwards compatibility (maybe they will just be typedefs, I'm not sure yet). But maybe I should provide a custom type to demonstrate how the transparency can work (and to make sure it does work!).



Do you mean for the purpose of supporting transparency in the marching cubes surface extractor? Actually I was only planning to have transparency in the CubicSurfaceExtractor. And it will not be possible to run the marching cubes surface extractor on a Material8 volume because I won't define an asDensity() function which takes Material8 as a parameter (so it will be a compile error). Or maybe I should, in the same way that getDensity() currently generates it based on the material. I think that is confusing though...

Anyway, thatnks for the feedback

Reading this I'm wondering how we will be able to tell the mesh what material to render as. It seems to me that the CubicSurfaceExtractor does need to care about materials.

I use a method like the following to tell my shader how to colour a particular vertex. Will this how will this be supported of the CubicSurfaceExtractor doesn't know or care about materials?



This seems fairly fundamental so I've probably missed something obvious.

Cheers,
Charlie

Yeah, actually I was simplifying a bit. The CubicSurfacExtractor does need the material because it will assign it to the mesh, but I really meant it doesn't need to perform any logic based on it. The logic is captured by the isQuadNeeded() function which will return the material to use (presumably one of the two input materials) as well as a bool indicating if a quad should actually be generated.

Just a heads up that the Git repository is becoming a bit of a mess as I make these sweeping changes. Those of you with personal clones might want to not update until things get sorted out.

@Matt - There will probably be some Linux issues over the next couple of weeks which will upset the CDash machine. I don't think we should try to fix these quite yet as I'd like to avoid any merging problems.