Yes, the PolyVox LargeVolume is the same now as compression has been removed in the 'volume-work' branch. Each block still just a flat 1D array with 3D indexing, but in the future I might be interested to see how Morton/z-curve ordering performs. I'm also in the process of switching to shared_ptr<> for block managment as it seems this will make it easier to track which samplers are using a block before it gets deleted.



Very smart move - I still think that overlapping data causes more problems than it's worth.

Ok, these changes are well and truly underway. So far I have:

• Eliminated compression from the LargeVolume. All blocks are stored uncompressed and as a result the code is both simpler and faster. Users can still compress data as it gets paged out (and this is what we do in Cubiquity).
  
• Switched to using smart pointers to manage the blocks. This should fix some bugs (e.g. previously a block could get deleted by the volume even if a sampler was making use of it) and should also be a step towards improved thread safety.
  
• Switched the internal block storage from using std::map to std::unordered_map. This means block lookups are now hash-based which is noticeably faster.

In terms of performance and general architecture the new LargeVolume is now somewhere between the old LargeVolume and the SimpleVolume. I think there is no longer any value in maintaining both these classes as they have become quite similar. I propose that the volume work described above becomes known as 'PagedVolume' (because is supports paging of data) and that both LargeVolume and SimpleVolume become typedefs of this to maintain some backwards compatibility.

Very good! I've been closely following at BitBucket and was wondering what direction you were taking with all the latest commits.

So if I'm correct there are only two volume types remaining, RawVolume and now PagedVolume?

If I may ask what are the key differences between Raw/Paged Volume?

Smart pointers are a great choice however I've stayed away from shared_ptr at all possible costs due to their performance implications, unique_ptr has little to no extra performance overhead compared to just using raw pointers. What is keeping you from using unique_ptr and it's ::move member function over shared_ptr?

_________________
Dream Big Or Go Home.
ENet - http://enet.bespin.org
Recast - https://github.com/memononen/recastnavigation
Irrlicht - http://irrlicht.sourceforge.net/forum
PolyVox - http://www.volumesoffun.com/phpBB3/
Help Me Help You.

Yes, this is the case. The PagedVolume is a kind of hybrid of what the SimpleVolume and LargeVolume used to be.

The basic difference is that RawVolume keeps all it's data in a single large array, which is created and destroyed with the volume. This makes it very simple (useful for debugging), often faster, and easier to do threading. It serves as a useful reference point.

By contrast the PagedVolume stores it's data as a large number of chunks which can move into and out of memory on demand. This means the volumes can be much larger, but we have the overhead of searching for the right chunk and we need to avoid the situation where one thread causes a chunk to unload when another thread is using it.

Both have essentially the same API, and in many cases you can simply exchange them.



I'll keep an eye out for this but basically we will follow the profiler. The idea is that a user can access voxels through the usual getVoxel() method in the volume interface, but they can also sometimes get references to the chunks which contain the voxels. Because chunks can get deleted when memory is low we need to keep track of whether they are being used anywhere else.

shared_ptr isn't the only option but I believe it does help with thread saftey in this regard. It's mostly an internal detail anyway so it can be changed if need be.

Ok, this work has now been merged into the develop branch. There are interface breaking changes, but nothing too drastic and all the examples/tests have been updated. Just post here if there are problems converting your code or getting it to work.

There is still more to improve in the new PagedVolume but for now I have to shift focus back to Cubiquity. PolyVox has had quite some work recently with the new volume, faster surface extraction, and support for 16-bit index buffers. I'll get all this new stuff integrated into Cubiquity as well and then see what comes next.

Basically, RawVolume is just plain old 3D array of user data.
LargeVolume can be used for very, very good 3D-indexed containerm like std::map - and its BorderValue feature is making this container something perfect for this purpose.
I ended up using this for storing ordinary data, for example, data about chunk entities, players and so on, without even using polyvox surface extraction. My "Voxels" became pointers to classes with world paging data, and I hope that PagedVolume will still benefit from this kind of usage. Especially if we can manually serialize pages from PagedVolume. (This is feature that will greatly help everybody, but as of now, I ended up with my own paging implementation)

As for now, I do not use PolyVox containers at all. With only one exception.
In Crafterria, I keep my world in chunks of plain 1D arrays (with 3D indexing).

When I extract the surface, I copy the data from the World data to a PolyVox RawVolume...


...to a RawVolume slightly bigger than the requested chunk (taking 2 voxels for surrounding chunks) - because these voxels are required for normals. But then extract the mesh without this overlapping, so I solved my overlapping problems once, for a long time And my chunk sections line up perfectly And my lighting pass per chunk is now... 15ms This is magic ;] ~1.2 seconds to light 8x8 world (64 chunks) - Faster than extracting their meshes, generating Splatting Index textures and generating the Light Texture itself

Soon, I will update the Crafterria post in Showcase -but I have a lot of work to do with it first.

Yes, this is all still possible. The PagedVolume is templatized on VoxelType and serialization still works.



Looking forward to it :-)