Over the last week or so I've been working to allow different volume representations to be used in PolyVox. The idea is that rather than there being a single volume class (currently called Volume) it will be possible to have more than one, and for people to choose the class which is most appropriate for their needs.

So far I have renamed the existing 'Volume' class to 'LargeVolume' and have added a new class called 'SimpleVolume'. LargeVolume continues to support compression and paging, and currently stores its blocks in an std::map. SimpleVolume is, well, simpler. It uses fixed size blocks stored in a fixed size array and avoids any STL containers.

Hopefully SimpleVolume will address some of the problems people have had with the new Volume class, particularly with speed and threading. It also provides a simpler example of how volumes should work and a basis for people to create their own if they need to. People have also been talking about copying data from one volume to another to allow multithreaded surface extraction, and the SimpleVolume might be useful for this.

However, to implement this I've had to break the interface to PolyVox. In particular, algorithms such as surface extractors are now templatised on VolumeType as well as VoxelType.

So instead of something like:



You will need to use something like:



I'm not yet certain exactly which algorithms this is going to affect. Also, the VolumeSampler has been moved to be a nested class inside whichever volume you are using. So if you want to create a volume sampler then instead of:



you now have to use something like:



This may change further in the future.

Anyway, do the class names make sense? I was also thinking 'AdvancedVolume' vs 'BasicVolume', 'LargeVolume' vs 'SmallVolume', etc? Any thoughts are welcome. I guess in the future I could imagine ThreadSafeVolume, OctreeVolume, RawVolume, etc?

It's not finished but in princple seems to be working out ok. But I'm not going to get a chance to do any coding for the next week or so, so will pick it up after that. In the meantime I would not recommend you get latest from Git as it's a little messy at the moment

Why not have LargeVolume and SimpleVolume inherit from Volume so no template is needed?

Mostly for performance reasons. Passing the volumes via a pointer to a base class would require the getVoxelAt(), setVoxelAt(), etc functions to be virtual, and hence incur the cost of a virtual function lookup. I haven't profiled this but potentially it is expensive and such fundamental operations are called a lot. By using templates instead this overhead is avoided as the polymorphic behaviour is resolved at compile time (static polymorphism).

That said, I have been considering introducing a base class anyway, simply as a way of specifying the interface and so people can ensure their own volumes have the required functions. The same applies to the VoxelType class, at the moment if people want to supply their own implementations it's not entirely clear what functions they need to provide. Having a base class would make this clear, while the algorithms could still be templatised to avoid the virtual function lookup. But I haven't yet fully thought through the implications of this.

What you are describing is equivalent to the Boost Concept Check Library (http://www.boost.org/doc/libs/1_46_1/libs/concept_check/concept_check.htm), which implements Concept Checking (https://secure.wikimedia.org/wikipedia/en/wiki/Concepts_(C%2B%2B)), a proposal for C++0x, which was apparently rejected in the end.

There are trivial ways to do this, for example, to insure a certain function exists, you can simply call that function ... etc. and you can wrap such calls in a "concept" a class that takes the user supplied class as a template type, and will result in compiler errors if it doesn't match. Boost Concept has a tiny learning curve, but good documentation. The errors might not look so nice though; but IIRC they are a great improvement over bare template errors.

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

Interesting - I wasn't aware of the concept of concepts in C++. Too bad they didn't make it though into C++0X as apparently they were considered quite a core feature at one time. But as you say, there are other ways of implementing the same idea, so I'll check out the Boost stuff at some point and have a think about what is appropriate.

If you've ever looked the the most common documentation of the STL, at SGI, you might not have noticed, but they use concepts to convey type requirements (InputIterator, OutputIterator LessThanComparable, etc.). It is part of what makes their documentation feel ... so right. However, their concepts are unenforced, and using the wrong type can result in the notoriously long errors that compilers spew for templated code, or perhaps it would even allow erroneous code to compile ... which is where Boost Concepts comes in; they enforce the concept, and make an attempt to give sane(r) errors.

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

There's an interesting article from Herb Sutter on his blog shortly after the meeting where they decided to remove concepts from the standard. I was quite looking forward to their addition but I guess we'll just have to wait until the next standard It's good to know that it's possible to emulate the feature using a library though.

_________________
Matt Williams
Linux/CMake guy

We've discovered that PolyVox no longer compiles on GCC 4.3, apparently due to the more advanced use of templates. Is that going to be a problem for anybody? I believe the current version is 4.6 and 4.4 came out a couple of years ago.

We haven't tested on Visual Studio prior to VS2010 either, so if anyone tries with VS2008 (using Boost, as VS2008 doesn't support C++0x) then we'd be interested to know if it works. Not sure if we'll be able to fix it if there's a problem though.

I now tested VS2008 and it still seems OK. At least in terms of the new template stuff - actually it turns out that VS2008 doesn't support the std::vector cbegin() function but I can work around that easily enough. This does mean VS2008 builds have probably been broken for a couple of months - is anyone still using it?

Anyway, it looks like it's only GCC versions 4.3 and earlier which have an issue.

Humm, just came across this: http://opensource.imageworks.com/?p=field3d, its a library made by Sony for Sony Pictures Imageworks, to store voxel data. Might be worth a look for a few different types of Volume implementations. I have to admire Sony for making that open source. I will definitely try swapping it as a Volume once I have everything else down.

Some highlights:





Other links:
http://sites.google.com/site/field3d/
https://github.com/imageworks/Field3D

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