I'm making some changes to PolyVox to remove the use of template template (not a typo!) parameters. Many algorithms access to the type of the voxels in the volume on which they are operating. Currently the CubicSurfacExtractor is defined like this:

and the voxel type is used internally like this:

User code to create the CubicSurfaceExtractor looks like this:

In the new version of the code the CubicSurfaceExtractor is only templatised on the VolumeType:

Because algorithms still need access to the VoxelType it is now provided as a member of the volume, and used as follows:

This is similar to how value_type can be used to determine the type of elements in an STL container. From a user code point of view, it means the creation of a CubicSurfaceExtractor should now be as follows

It's very similar to before, so you'll have to look carefully to spot the difference

The main motivation for this change is that template template parameters get complex and result in hard to read/write code inside PolyVox. Frankly, it was done using template template parameters I the first place because I didn't realise there was a another way. Another advantage (untested) is that you should be able to use typedefs of volume more easily:

I'll probably change all of PolyVox's algorithms in this way, unless I come across some specific cases where it doesn't work.

*thumbs up*

_________________
irc://irc.freenode.net/#polyvox

This is good news. As far as I can remember, template template parameters were one of the main things preventing me from getting SWIG working properly with newer versions of PolyVox. Once this has all settled down, I'll take another look at getting the SWIG bindings working.

_________________
Matt Williams
Linux/CMake guy

Ok, I think I've now changed all instances of this. It's nice getting back into PolyVox after so long focusing on the game side of things



Yeah, they certainly complicated it. If you don't get around to it I might take a look at them myself in the future, as I think you can imagine how they could be useful for a certain top secret project...

It's looking good. I've just made a commit to fix the compilation on GCC. It's much pickier about including 'typename' before scoped template parameters when there's a chance that they might be a member variable rather than a nested type. I had to add about a million of them but it's compiling now.


Yeah, they could certainly be useful. I'll try to have a look at at least getting build system for SWIG working again and at least PolyVox::Vector building so that we can take it from there.

[edit] I've just re-enabled the SWIG system and it seems to work for me. I've commented out everything except PolyVox::Vector for now but I expect a number of other systems will work well straight off. The interface isn't at all Pythonic but that's something we can add as we go along. [/edit]

_________________
Matt Williams
Linux/CMake guy

Yeah, sorry about that This typename keyword is something of a recurring problem as VS simply doesn't complain about it. Also I realise I committed my changes but didn't push them (still being caught out by Git!) so I'll do that later and check how it is working on Linux.

Ok, I've pushed them. I've also compiled on Linux and made some more fixes.

I'll be curious whether the CDash machine works tonight. It's been a long time since we had a sucessful build on that but on my own Linux box everything is fine.

Ok, build machine is running again The A* test is failing, but interestingly that's the one which has always given different results between Linux and Windows. Maybe it's failing because the tests now match? That would be nice, I'll check it next week.

Unfortunately, it's still inconsistent. It's just inconsistent in a different way now I've looked into the changes needed to make it pass and in many cases, the y and z components are just swapped but some others needed more changes. It's still quite worrying that Windows and Linux don't match here and it's definitely something we need to track down before we make the next release. In the meantime, I'll commit my 'fixes' so that the test passes.

In good news, the removal of the template template parameters has enabled PolyVox to be build on GCC 4.3 again. I had to switch the CDash build machine to build using 4.4 previously. When I get the chance I'll re-enable 4.3 so we can get build tests for both.

_________________
Matt Williams
Linux/CMake guy

I've now done this and PolyVox is building for GCC version 4.3 through 4.5 and can be seen at my.cdash.org. My next task with the build server is to look into clang but that depends on them providing it.

_________________
Matt Williams
Linux/CMake guy