Ok, I had a go at testing this on Windows, but I hit a couple of problems (no doubt due to my rather weak Python knowledge).

Firstly, I couldn't get it to build in debug more as it was searching for python26_d.lib, whereas only python26.lib exists. I'm sure we can fix that in CMake.

Secondly, it did build in release mode but I couldn't manage to use it. It generated four files:

• _PolyVoxCore.exp
• _PolyVoxCore.lib
• _polyvoxcore.pdb
• _PolyVoxCore.pyd

I copied all of these into C:\Python26\Lib\site-packages and ran Idle. It went like this:



I'm not sure why I need the leading underscore to import the library (that's probably a sign of a problem) or why I can't create the class.

However, when I type 'pv.' I see Python's version of Intellisense pop up:



It looks like it can see the member functions, but not the actual class? Any ideas?

As well as those files with leading underscores, there should have been a PolyVoxCore.py file created. SWIG works by making a dynamic library(ies) with the leading underscore which contains the wrapper between C++ and the Python C API and then a .py file which provides a nice Python API.

If you don't have the PolyVoxCore.py file then there's something wrong but I can't guess what.

If you've got the .py file then you should be able to just run IDLE from the PolyVox build directory (library/bindings) and it will work.

_________________
Matt Williams
Linux/CMake guy

Ok, I missed the PolyVoxCore.py file because it was in a differnt folder to the others:



PolyVoxCore.py is where you said, but the others are in Release/Debug subfolders.

Anyway, if I copy it all to 'C:\Python26\Lib\site-packages' then it now works as expected But I didn't manage to get it to work without copying them to a new location.

I guess those subfolders are a problem. Our installer can just move the fies around of course, but I wonder if there is any way to make the source distribution work as well?

Yeah, PolyVoxCore.py will have a relative (current directory) search path (like `import _PolyVoxCore`) inside it so it won't find the .lib unless it's in the same folder. For testing you can copy/move the PolyVoxCore.py file into the Release or Debug directory and run IDLE from there to get it to work.

It's possible that there's a SWIG option to allow relative paths but it might then be tricky to change it back at installation time. I would guess that it's even less common to run the Python bindings from the build directory than it is for C++.

I tried playing around with PyOpenGL (tutorials at http://pyopengl.sourceforge.net/context ... ndex.xhtml and http://pyopengl.sourceforge.net/documen ... index.html) but my open source nVidia drivers in Linux only support OpenGL 1.4 so I didn't get very far. PyOpenGL supports VBOs so it should be able to do the equivalent to the C++ demos.

_________________
Matt Williams
Linux/CMake guy

Yeah, I think we can leave it at least for now. It works on Linux, and it works on Windows if the user just copies a couple of files to the right place.

That said, maybe it's possible for CMake to move the PolyVoxCore.py file into the the appropriate subfolder? Or for SWIG to place it there as it's generated? E.g. Replace:



with:



Or maybe go the other way, and have CMake copy the other four files up a level, so it matches Linux. Well, maybe it's not a good idea as eventually the installer will take care of it...



It's actually possible to use old 'immediate mode' OpenGL to render PolyVox (search for 'm_bUseOpenGLVertexBufferObjects' and you'll see the OpenGLExample has some code for it). It's not a great idea though as you'd be learning really out of date stuff. But maybe you can switch to pure software rendering (Mesa?) if your drivers won't handle it?

Also, is it possible to add a unit test for the Python binding to make sure they don't get broken again? I guess the CDash test machine won't have SWIG installed. I actually added another test today (TestAmbientOcclusionCalculator) and will try to add some more.

I don't have experience with Python + SWIG on Windows, but some general python knowledge.

Did you know that you can use PYTHONPATH to specify where to search for python modules? This works from either the shell environment, but you can also do it from python code as well:

Thanks, but the problem is more that the files generated by CMake/SWIG are not all in the same folder. But I think we can just use use CMake to move the files around.

@Matt - I think we just want to copy PolyVoxCore.py from ${CMAKE_CURRENT_BINARY_DIR} to ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_BUILD_TYPE} as CMAKE_BUILD_TYPE contains the string 'Release'/'Debug'/etc. But actually I don't even know enough CMake to do this - I came across file, copy, install, configure_file, add_custom_target, etc but I'm not sure which one should be used?

Also is it possible to set the name of the SWIG target? In visual studio it shows up as _PolyVoxCore. And I guess we need to make this target a dependancy for the copy?

The problem is that it's not easy to add a post-build step to a target. We've used things like configure_file() in the past for copying files around but it's always been as a pre-build step (filling in details in Doxyfile for example). It's made more difficult be the following problem:
The issue here is in the wrapper provided by CMake for SWIG. For some reason it doesn't add the bindings as an add_custom_target but simply adds it to the ALL target. The upshot of this is that's it's currently impossible to choose not to build the bindings at compile time -- they could only be disabled at CMake configure time (once I've added that option). The fix to this would probably be to include a hacked version of UseSWIG.cmake in PolyVox and submit the changes upstream in the meantime. It shouldn't be too hard but I think that it should be done before enabling the bindings by default.

_________________
Matt Williams
Linux/CMake guy

Ok, I see. Well it's not really a problem as the bindings can still be used by copying the files to the right place. I just thought it would make it easier to set up an automated test, but it sounds like it can come in due time.

Whats the state of the bindings right now? I had some good intentions of getting something setup for a sample tutorial and easy instructions to setup C# library but it looks like there are things that are not working correctly still. I was sad to see this discussion stopped a long time ago.

I wonder if this is dead? it's been 2 years. I'd like to help if I can.