milliams wrote:
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?
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.
milliams wrote:
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.
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
Code:
typedef CubicSurfaceExtractorForSimpleMaterialVolume CubicSurfaceExtractor<SimpleVolume, Material8>
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?