Can't check right now, but IIRC the problem with using the vertices as particle emitters is that they aren't evenly spaced, you'd get spots with a lot of emitters (small triangles), and areas with less emitters (larger triangles) with the marching cubes algorithm. So getting a surface point extractor that gets a homogeneous spacing between points should be useful. Having a higher resolution grid than the voxel data grid should also be possible.

Would love to have the time now to test things out instead of just speculating
Will experiment with using vertices as particle emitters and see how it turns out before writing any code for the smooth surface point extractor (As I've just dubbed it).

Well you're certainly welcome to give it a go, or to just create a test scene and see how it performs. You may even find that there's a different limitation of PolyVox which prevents you achieving what you want, and maybe you could address that instead.

And don't worry about time, there's no hurry from our point of view. Quite the opposite in fact... I'm just getting back to PolyVox after Voxeliens and need to get it into shape before we can accept user contributions.

Well the (cubic) SurfacePointExtractor seems to be working and I've created a unit test for it. Will write the swig bindings soon so that I can test it properly in Panda3D.

Also, what should the output type be for the extractor? Currently I'm using an std::vector of Vector3DInt's.

Excellent stuff! I'll look forward to seeing it in action. Are you working against the last stable snapshot or against Git?



The Python bindings are reactivated in the latest Git, but you may have to make some changes to get you code compiling with that version.



I think that is fine for now, but we need to unify this in the future. We are coming to the situation where different surface extractors are having different vertex formats (some have materials, some have normals, etc, and I think TVA will be a little more complex) so we need a solution to this. But we'll worry about that in the future, for now you can either output Vector3DInt's or use the PositionMaterial type.

I did use git head at the time when writing it so that there aren't any merge issues.

This does raise the issue if I should create a branch located just before the first time there were breaking changes to have a stable working platform for integration for my own projects/testing or to just keep up with git. But creating a branch so far back might cause duplication of work (eg. swig bindings ). Hmmm, I tend to follow git quite closely so in the long run it might just be easier for me too keep use of polyvox to a basic minimum until it's stable again but up to date.

I think adding unit tests for swig is something that should be looked at, much easier to keep track of breaking changes and its effect on swig. Not sure how that will be done because of the extended toolchain though.

If I were you I'd just follow the latest Git. The stuff I'm changing probably won't cause any problems for you, and it's settling down a bit now anyway.



I think it's in there though Matt can confirm. At any rate there is a test written in Python, and I believe it is tested in Linux every night. I also tested it in Wondows today.

I can't seem to find it, is it on git?

I did manage to create some tests for polyvox/swig using python's unittest framework, though I got stuck with the surface extractor tests.

We do currently have a test which runs using the SWIG-generated Python bindings and is run every night as part of CDash. It's just implemented as a single Python file in the tests directory called TestSurfaceExtractor.py and uses Python's unitest framework.

If you look in the CMakeLists.txt file for that directory, you'll see that to add the test to 'make test', you simply have to doYou can then run it as part of 'make test' or run it specifically with 'ctest -R PythonSurfaceExtractorTest'.

_________________
Matt Williams
Linux/CMake guy

Ah yes I see it's been added to git last month. I've been using git wrong so I didn't have the latest version.

Thanks for the tip.
PS. Enjoy your stay at the Develop Conference

[edit] Actually looks like I just didn't see it. :S

While trying to wrap my surfacePointExtractor I ran into the same problems that the CubicSurfaceExtractor had so I went ahead trying to fix that before working on the point extractor further. I got it working after a while...

So I made two major (but not breaking changes), I moved the declaration of the volumeSampler from inside the execute() function to a private member. I also moved the body of the execute() function to a private member function, and having execute() simply call that. That solved the problems with swig not being able to handle nested functions.
Also instead of using
for example, I used


Secondly I made a dirty fix in the interface file for the Cubic extractor by using %rename(getDensity) getMaterial; because for some reason swig claims that there is no member getMaterial for the voxels.

[edit] After writing all that I found another solution is using the SurfaceExtractionController and use it's converToMaterial method instead of calling getMaterial on the voxel directly, this removed the nasty %rename directive in the interface file.
[edit] I checked git and SurfaceExtractorController has been renamed to DefaultMarchingCubesController.


Ah, these ExtractionControllers will allow us to have a custom threshold values and it fixes some of the swig binding issues? Neat!