Interestingly there's just been a post about SWIG on AltDevBlogADay (great blog for anyone interested in game development). Point #7 is exactly what we are facing here.

The first comment suggests you can work around it by being explicit with all you class names. That would go against what the SWIG docs say but would be useful if true.

I didn't get to look at this over the weekend, but I did have a thought. I don't think the Volume::Sampler is used anywhere in the public interface of PolyVox. i.e. there are no public methods which take it as a parameter. Instead it is used inside things like the surface extractors to get faster access to the data.

So does that mean that the Volume::Sampler could be completely hidden from SWIG? It would mean people couldn't create them from Python, C#, etc but that's probably not a terrible loss. In most cases people will probably just be using the built in algorithms.

It might be a stepping stone anyway...

If the sampler's not needed directly by any user code then indeed I could probably just hide it. I think I'll have to surround it with some #IFDEF SWIG guards since at the moment the presence of an inner class causes Volume to not be bound either.

I might have time to look at this tomorrow.

_________________
Matt Williams
Linux/CMake guy

Yep, give it a shot. But I will try to have a look at it myself if you can't get it to work.

Ok, so hiding SimpleVolume::Block and SimpleVolume::Sampler from SWIG seems to make it happy so far. This makes me wonder, should these nested classes be made private/protected if they're not part of the public interface?

However, after this I found another SWIG bug/restriction in that it's a little picky about supporting template template parameters. It's complaining about PolyVox::SurfaceExtractor. I found this bug on the SWIG tracker which seems to match what I'm seeing. I've posted a question on StackOverflow to see if anyone else out there has any ideas.

_________________
Matt Williams
Linux/CMake guy

No, they do need to be public. They basically provide a fast way of accessing the data and this is useful to people implementing their own algorithms to run on PolyVox volumes. In other words, people are free to use the samplers in their code, but none of the existing public functions take it as a parameter and so SWIG doesn't miss it.

This might change in the future, and ultimatly it might be nice if people can access create Sampler's from their Python/C# code, but it's not too important.



Hmmm... Ok. The first thing I notice is that you are using SWIG 1,35, whereas version 2 is also out? I wonder if there is any chance this has been fixed.

One workaround which springs to mind is that maybe it's possible to create C++ typedefs for the surface extractors we wish to export. Eg



Then use #ifdef SWIG to hide the original declaration and only let SWIG see the typedef. Not sure if that actually works but it's food for thought.

Failing that, rather than being a typedef, maybe CubicSurfaceExtractorForSimpleMaterialVolume' could be a thin wrapper or subclass of the templatised version? At this point we are starting to wrap PolyVox in a simplified wrapper just for SWIG, so it could turn into a lot of work. Or maybe it's not so bad?

Ok, I'll leave it as it is at the moment then. Best to avoid making it private if you think it might be good to have it public again in the future.

I'd missed that SWIG 2 was out but I've just upgraded and the bug is still there.

I will give this a go in the week as it's only these more complicated template template classes that are having the problem.

Again, it should only be necessary for the more complicated functions. Either way, I don't think that it should cause too much of a problem. I'll approach it iteratively and only implement what's needed. On the whole, SWIG is fairly good at wrapping C++.

_________________
Matt Williams
Linux/CMake guy

Doing the typedef method didn't work since it didn't seem to be enough to convince SWIG to wrap it.

Instead I've had to give SWIG a dummy interface which wraps the template with a concrete instantiation. So far I've only fixed SurfaceExtractor<SimpleVolume,Material8>. See SurfaceExtractor.i to see what I had to do. It's unfortunately a bit manual but it's required to get round a bug with SWIG's %template directive which fails on template templates. However, it should only be required for the surface extractors for now.

As of now I can run the following Python codeand it will successfully print 3567.

Now I just need to learn OpenGL and PyOpenGL to visualise this

_________________
Matt Williams
Linux/CMake guy

Really excellent work

When I said it might be necessary to provide a simple wrapper I was actually expecting it would have to be done in the C++ code, but being able to do it in the interface file like that is much nicer.

I can see that doing it manually will get repetitive, but maybe it can actually be solved using templates? I can imagine that your new wrapper class could take a template parameter which tells it which class to derive from? Or maybe we're going in circles here. Again, I can a crack at it if need be. Otherwise maybe SWIG has some kind of macro support, or maybe normal C++ macros can be used (they are just string replacement after all)?

I'm just in the process of doing a stable snapshot, after that maybe you can reenable this in Git and I'll make sure it doesn't interfere with anything in Windows.

Yes, definitely. I wanted to avoid using #ifdef SWIG as much as possible.

As far as I can tell it works like this:
SWIG obviously needed a concrete instance of a template to work with and so it needs to at least know the types you want for the template parameters. At its most basic you have to do what I've done in the SWIG interface file and give it a non-templated class to work with (this is covered in the SWIG C++ page).

To make life easier SWIG provides a %template directive which works similar to a C macro so it just does a bit of keyword substitution (and maybe a little parsing) to create the appropriate concrete interface for the templated class including the public methods. However, the %template directive fails when trying to parse template template parameters.

I suppose it may be possible to define a SWIG macro to cover the simple case we need since we don't require a full parser (we only ever have 2 parameters for the extractors.) -- I'll have a look.

_________________
Matt Williams
Linux/CMake guy