Maybe, though I'm trying to avoid external dependancies for PolyVox where possible. But actually I don't think anything as complex as ZLib is needed - I'm pretty sure a standard RLE algorithm would give good results and I already have some code lying around.

I haven't follow the "volume divided in chunks" path, but instead the -IMO much easier and intuitive- "one volume = one chunk" with a layer on top of all chunks coordinating PutVoxel/GetVoxel/Save/Load/Generate operations into all volumes seamlessly.

Using this, threading was extremely painless and I haven't got a single error yet

I'm not saying this is bad, but it is a bit redundant. You are talking about about storing several volumes and then providing a coordinating layer for getVoxel(), etc. But this is what PolyVox already provides, in that a volume is stored as a number of Block objects (each with a getVoxel() function), and then the volume's getVoxel() function calls through to the one in the appropriate block.

The reason that bezyend is using multiple volumes is in order to page them from disk on demand in order to create infinite terrain. There might be other reasons - if for example you had a space scene where each volume was an asteroid and there were large gaps between them. But generally it not how I anticipated PolyVox being used (though sometimes it's good to think outside the box ).

Well, that's another of my reasons too =p

Well in that case go for it... Eventually I may add built in support for infinite volumes but it won't happen for a while.

That's how I did it initially, one coordinate system for paging (using Ogre's paging system) and is mapped into a set of PolyVox::Volumes with single data chunk defined for each volume. Then I went and changed this because (OCD issues? lol) I was "trippign" about borders between chunks (okay granted I didn't spend too long thinking how I can resolve this and keep the same system) so that now I have multiple chunks of data per PolyVox::Volume chunk, and another level of mapping from Ogre's coordinate system into the final (local) coordinate system. So it's Ogre's -> Volume's -> Volume chunks. I'm going to stop worrying about this. It's not perfect but it works.

And I'm not doing moving coordinate frame thing where I map all pages into a single PoyVox::Volume; I'm instead dynamically allocating PolyVox::Volume as I go. I know it's not perfect solution but I don't really care anymore.

Also, the first thing I tried before the current solution is I tried generating the needed borders per Volume chunk. THat is, generating one less than "power of two" voxel value, and with the "power of two" voxel value matching the value of the next chunk. But there was some trouble with that and I ended saying screw it and went with my current solution.

I was going to pass in a border cache from my noise generator into the surface extractor so when they need to evaluate an border then can get it from there, but I was lazy and didn't implement this, and went with my current solution.

In the future I may have to go back to a thin layer between PolyVox and my generation method; the reason is that my current method can have memory leak issues due to block mangement with PolyVox::Volume and the way I'm using it with threads. So the thin layer will use an atomic variable, so that the first thread that generates an border value will be responsible for generating that border value. But you say, that makes no sense. Well, the thing is, with memory access pattern currently this rarely happens (i.e. the voxel being set is always going from left to right, so --in most cases-- by the time one gets to the border, that value has been generated--it is the left-most value for a region). I can live with the occasional exposed borders. Mind you though, all this border issue is really a non-issue, it doesn't really affect the performance at all!!! So my advice is to just ignore the borders. (well I comfort myself on the time wasted on this with --hey man , it's for teh physics.)