I have an idea for multithreading that does not require any thread safety of the volume class.

1. loading parts of the volume in another thread

create a second volume in the other thread, load your data there
once some parts are loaded and you wish to put this in the main volume,
use a mutex to block access to both volumes and call a (not yet existing) function of volume that overwrites part of a volume (your main volume) with part of another volume (your second volume)
this function will probably invalidate the first volume (otherwise this would be slow I believe, and your data is where you want it anyway)

2. unloading parts of the volume in another thread

this works just the same, you move with the not yet existing function part of the volume to another volume, this will erase the content that was inside the region you moved and place it into the other volume.
after you have done this, you can safely unload everything that is in the other volume, even if you do so in another thread



I believe a move command that modifes the internal structure of two volumes to be very fast.
any thoughts on this?

So just prepare the buffer ahead of time?

Will the copying of voxels be a big slow down though? as we need to do SetVoxel for x, y, z

I don't know could be worth a shot. At first I thought why not just have a PolyVox::Array in your loading thread instead of the Volume. But with the new compression features your "loading" Volume in the other thread can be under compression so it saves up memory, I guess.

You could only keep maybe a few of these (ex: four loading volumes for four threads) and use it as a writing area for any load request. This facilitate reuse also. This would work naturally with my current setup. Plus for me the amount of improvement I get from loading in threads may be less than a linear improvement (I need to profile this part more), however it could be worth a try.

I may try this scheme soon just with PolyVox::Array since I'm still working off Trunk. In my app the memory usage pattern of other parts of my system overshadows that of what PolyVox uses, so it may not be too much of a burden to add these loading Arrays.

What about speed? Right now, I generate PolyVox::Mesh in the other threads, then copy into Ogre::ManualObject in the main thread. It's not too bad but then again it's not copying an entire Volume region. I don't know.. could be fast. The ideal way is to copy the memory blocks directly.

shanee: you misunderstood my whole point or I misunderstand what you mean now...
there will be no slowdown in the move from the extra thread to the main thread, it will be internal

beyzend: I have not thought about this at all.
but sure, copying parts of a volume could still be faster than doing so manually through getVoxelAt.

for me it doesn't matter how much time is wasted in the extra threads... I just want my main thread to keep a steady x fps that I define.

I just got an even better idea
it would get rid of ANY memory copying.
and allow for true multithreading by splitting up the volume while still keeping it as one volume for the main thread....
but I need to fill some notebook pages with drawings first before I'm sure it can work and be useful.
I'll post tomorrow (It's kinda late here, sorry ^^)

Well, in case you are generating pages you can order your pages to lessen dependencies. I don't know how it will apply to your case but in my case I need to resolve this thing with sharing of borders between pages. I'm not really ordering my pages right now to "lessen" this dependency since I'm using Ogre's paging system, I have no control over the order of pages. But when I do implement my own paging system I can order them. At least I hope there is a way to order them like that.

Just skimming over this, there's some interesting ideas. It seems your basically looking for faster ways of getting data into and out of the Volume - such that one thread can prepare the data (as slow as necessary) and then the main thread can quickly copy it in. There is some potential in this - for example perhaps a setVoxelsAt() function which takes a Region and a 3D array of data. Or maybe the ability to copy part of the data into a smaller Volume which can then be used with the surace extractors on a different thread.

I'm not going to look at anything like this for a while, but of course other people are welcome to try. But for now the priority has to be finalising the paging volume and getting it merged into the trunk. Then Matt will take care of moving it all across to Git. From then on it should be easier for people to create clones, work on these, share tham, and potentially merge them back.

I was actually trying to get rid of any copying by doing all of this inside the volume class...
not even copying for that matter, but just ripping out the blocks from the one volume and placing them into the other volume.
basically ending up only having some pointer replacements and timestamp updates

but even copying should be faster if it is done inside the volume class and not through some extra functions that need to check for Block boundaries and stuff.

yes I did not intend to actually try to implement any of this before the git repos is available.

yeah that's cool. Just have your main volume shadow the thread volume. Then just swap pointers. Hmmm...

and tell the main volume that a certain region is not accessible for it at the present time... (or certain regions for that matter)... or force the user to check for this and say behavior is undefined for accesses to regions which are in another thread ^^

okidoki, I see why my idea was somewhat unlogical.
if I use pointer swapping, it gets very messy for the user.
copying is much nicer.

for anyone willing to work with block (note: block != voxel) coordinates, try out my fork of polyvox.
https://gitorious.org/~ker/polyvox/kers-polyvox

It's as simple as manually looping over all the voxels in a block and writing them to the other block. I'm sure a memcopy would work, but maybe not for all voxel types.

my setup is the following:

a mutex to protect the volume.
a second volume inside the thread.
whenever I want to render some part, I copy all the blocks touching that part and that have been modified since the last rendering to the second volume (and locking the first volume the entire copying time).

the copying takes less than one ms for 32^3 blocks in debug mode.

There is an untested function for people who want to use regions instead of block coordinates. But it only works for regions that are aligned to block borders.

I attached a not yet cleaned up or commented version of my ThreadedVolume class to this post. it has no dependencies except for boost, PolyVox (obviously ), and some PolyVox Helpers of mine (also attached)

I hope the interface is self explanatory, otherwise, just ask