I've seen multiple people on this forum that started using PolyVox and hit the problem of multithreading their application. Those who do not know what I'm talking about, read this.

Solutions to PolyVox and multithreading vary. I've seen using a mutex to allow one thread at a time to access the volume, creating a separate volume per "threaded chunk", and even creating their own volume type.

I'm yet another victim of PolyVox' lack of multithreading support. Having used all the different types of volumes, my needs have boiled down to these:
- Thread safety
- Serialization (save to/load from disk), preferably compressable.

I was impressed by the complex LargeVolume which has advanced paging capabilities, but lacking thread safety, and missed awareness of which blocks are loaded and unloaded. On the other hand, I was happy with the simple-yet-effective RawVolume which in turn lacks serialization.

So I decided to combine the best of both worlds. I've added the functions 'getData' and 'getDataSizeInBytes' from LargeVolume to RawVolume, giving the volume the capability to be serialized. Next I duplicated MinizBlockCompressor and renamed it MinizRawVolumeCompressor. The name says it all; it accepts a RawVolume, using the 'getData' and 'getDataSizeInBytes' functions, and compresses it into a CompressedBlock which is then serialized to/from disk.

In my minecraft-like terrain, terrain consists of chunks of 16x16 blocks, and a RawVolume consists of 16x16 chunks. With the abovementioned solution, I can easily manage loading/saving the RawVolumes, yielding my infinite, procedural terrain.

I felt like sharing this solution to PolyVox and Threading as it might bring future PolyVox users up to speed. Any thoughts or remarks are more than welcome.

Sounds interesting :-) Overall I'm still not a fan of using multiple RawVolumes because of the problems it causes on the boundaries between volumes, but it seems that many people are getting away with this. You're working with cubic surfaces which are easier than marching cubes surfaces in this regard.

The next volume class (PagedVolume?) will initially be a simplified version of LargeVolume, and will later have threading support added. In this sense it is similar to what you describe (but managing multiple chunks rather than multiple RawVolumes) and it will abstract away the boundary problems like LargeVolume does.

I implemented threading on my Irrlicht project by using multiple volumes, I just had to fill in a border area around the volume data with the information from surrounding volumes so that the marching cubes would properly extract the edges. The end result was fine and I didn't have any issues with it.

I also use Volume-per-chunk approach in my current code and it works flawlessly if you can handle implications and keeping data overloading cases in sync. Threads then access volumes and lock them with mutexes.

Also, I ended up modifying MarchingCubesSurfaceExtractor to use my Volume Manager accessors in borderline cases.