NOTE: This thread has been split of from a previous thread about compilation problems. You can read the previous messages here: http://www.thermite3d.org/phpBB3/viewtopic.php?f=2&t=105

I did indeed start work on the bindings but without concrete users it was difficult to know where to focus my efforts. I didn't get very far and perhaps SWIG was too much of general-purpose too to be using. I've been tempted to look into using SMOKE, the tool designed and used by the kde-bindings team. It's usable by non-Qt based projects so I think it could be a good tool. Also, being designed for wrapping C++, it will cope just fine with the use of templates.

Regardless of anything I'm planning, I would be very interested to see the results of your efforts.

_________________
Matt Williams
Linux/CMake guy

That's interesting. Within Thermite3D I've been using the built in QtScript bindings to provide a scripting interface. It works fairly well but I don't really like QtScript that much... the lack of operator overloading is particulaly annoying when dealing with vectors/matrices. Maybe I'll look at SMOKE at some point in the futire for that purpose.

hi!

i tried to wrap polyvox for python in the past. the heavy use of templates is a big obstacle to overcome. cython does not support wrapping integer type paramater class templates, yet.

I also tried PyBindGen, Boost.Python, SWIG and SIP. SIP, i wasn't even able to build I gave it up weeks ago and started to implement my own marching cubes in python/cython. If you get it to work freakazo, please share yout work

best regards, Sebastian

Haha wow loschi, it feels like I'm talking to myself
Cython obviously isn't perfect for wrapping up Polyvox, and for me at least compared to other libraries pretty damn hard. So I'm experimenting with using this and then when needed throw in some static declarations for cython to speed things along and build up a package similar to Polyvox... hopefully that is

Will certainly keep my eye on Polyvox, a good library and a good community

hrhr, i used p3d as a blueprint for my own MC implementation . but i would love it, if i could use PolyVox with Panda3D ( Python Game Engine).

Sorry to go quiet, I didn't get much of a chance to post over Christmas. Just catching up now...

Anyway, it seems that PolyVox's complexity (particularly regarding templates) is the main obstacle to wrapping it with the various automatic bindings generators. So perhaps the easiest way to use its functionality in your projects is to first wrap it in a simplified C++ library (exposing only what you need) and then expose that library to Python using SWIG, etc.

For example, you could create a C++ library with a class 'MyVolume', and internally this class could store a PolyVox::Volume<Density>. You could also give it an 'extractSurface()' member function which internally creates and uses a MarchingCubesSurfaceExtractor. But these implementation details would be hidden behind the MyVolume interface, which wouldn't even need to be templatised. Your new library now has a much simpler interface which could be easily wrapped.

Of course, the next logical step would be for this simplified library to become an official part of PolyVox. There's already PolyVoxCore and PolyVoxUtil, so perhaps PolyVoxBind could be added. In this case it might not want to be quite as simple as in the example above, but just simple enough that SWIG, etc can handle it.

I'll gladly help out with any efforts to achieve this, and might take a look at it myself at some point. In fact I'll add it to the TODO list, but it's not something I personally need so it might not happen for a while.

I've spent a bit of time looking at this over the last few days and, with the help of milliams, have wrapped some PolyVox classes using SWIG. I suggested previously that it might be necessary to create a simplified interface for wrapping, but actually I didn't need to do this.

So far I've wrapped the Vector, Region, and Volume classes, and have been able to do trivial actions like creating a Volume from Python, setting a voxel, and printing out the size of the volume. So it works in principle, but to really be useful I need to wrap the SurfaceExtractors and SurfaceMesh class as well.

Unfortunately this is a bit of a distraction from other PolyVox/Thermite stuff I need to be working on... so I have to put it to the side for the moment. Hopefully I'll come back too it again in the future.

I've just tried to compile the latest version and it seems to be missing Density.i. Hopefully you have access to, or can reproduce this file to add to the repository.

_________________
Matt Williams
Linux/CMake guy

Yeah, looks like I forgot to add it after the bindings work I was doing. I don't have the original file but have taken a guess at what it was supposed to look like. If it doesn't work you can just comment it out in PolyVoxCore.i I think.

I greatly appreciate that you've put some time in it I think creating SWIG gluecode for PolyVox is a great gain for the project. Not only Python users will be able to use it, but also people working with one of the other supported languages.