I will add about threading.
Currently in my multi-RawVolume (with all of its implications) engine, I have mutex locking on the chunk sections and smart setter/getter stacking.
I lock() the chunk and then run the surface extractors / voxel data modifiers on this chunk from other threads.
If another thread calls my ChunkManager::setVoxel(x,y,z,..., bool important) with important=true, and the target chunk is lock()-ed, the operation is added to voxel updation map and performed in first gametick when target chunk is no longer locked. This way I ensure updation stays in sync.
Due to the fact every chunk have its own RawVolume, no threading races occur in PolyVox, but handling all the overlapping cases AND locked/unlocked cases is tricky.
You can consider similar locking pattern with LargeVolume and region locking. A thread can lock or as you named it,
pina region for exclusive access and not to be unpaged, and other threads should try_lock() / wait for unlock state before attempting to modify the locked region.
Proper thread-safety on
LargeVolume will definitely help me A LOT, because with Multiple Volumes I have to handle several issues myself, most notably:
[*] Overlapping 2 voxels is essential for proper normals,
[*] Updating 1, 2 or 4 chunks in case or border voxel coordinates,
[*] A* Path finding requires custom A* pathfinder class (I copied the one from PolyVox and modified it to use the Chunk Manager's accessors and lock-waits, which degrades performance, but as compensation it's thread-safe.
[*] Just Volume-per-chunk maybe isn't the ideal solution, I should implement volume-per-region approach and a region will have chunks, and chunks shuold have chunk sections (ehh,
Minecraft...). This way setting and getting data from volumes will require fewer locking, but Surface Extraction may not work flawlessly / well paralelised. I have to experiment how to balance the whole system.
BUT With current implementation, Number of CPUs REALLY help! People with Core i7 definitely get the best performance here because of paralelism, and people with single-core CPU s*** ****s
but as the target are gamers we can safely assert powerful multi-core CPU here
And real-life games we will definitely NEED to have a chunk manager anyway.
I am using boost mutexes here as Ogre already forces us to use Boost anyway.
p.s. my Chunk Manager's source code will soon be committed to a SourceForge repo.