Hi. I'm using Ogre's workQueue system to call the surfaceExtractor for different regions but I keep getting access violations when executing it. Am I running into thread safety issues here?

In a recent blog post I mentioned how we wanted to improve PolyVox's documentation before the next release, and there are a number of topics which keep coming up and which I would like to address. Threading is one of them, and so rather than answering your question directly I've instead added a section on threading to the manual.

It's not on this website yet (that will come with the release) but you can read it in Git here: http://www.gitorious.org/polyvox/polyvox/blobs/master/documentation/threading.txt

Have a read and let me know what you think. For you the two key points are:

• Yes there are problems with threading and LargeVolume (RawVolume should be safer).
• Even if you manage to do multi-threaded surface extraction then be aware that only the main thread can upload data to the GPU. This is a Direct3D/OpenGL limitation.

Hmm. Is the ray volume able to to grow like the LargeVolume? If not, can I use multiple rawVolumes?

No, and this is one of the reasons why it is easier to make it thread safe. The LargeVolume has to perform a lot of internal memory management (blocks of memory get added, deleted, and moved around) and this is why you can have problems when you try to access multiple voxels at the same time. The RawVolume is entirely fixed and doesn't move in memory, so accessing one voxel does not invalidate another.

This is actually quite a common question, so I've just added an FAQ entry for it: http://www.gitorious.org/polyvox/polyvox/blobs/master/documentation/faq.txt

It's a bit messy... I wrote it when tired. I'll tidy it up before release.

Basically, the answer is that you shouldn't do this because you will have problems on your block boundaries. PolyVox needs to get access to a voxels neighbours and it can't do this easily if they are in a different volume.

Thanks for the info. I was curious about adding mutexes to code that would read or write to the volume. Would this suffice?

You can add threading primitives such as mutexes to your code in order to ensure that the volume does not get accessed by multiple threads. This should stop the crashes occuring, but I expect it will perform worse than the single threaded version because still only one thread can access the data at a time and you'll have the overhead of the mutex locking.

I think the proper solution would be to modify the LargeVolume to make use of such threading primatives internally. It should allow the user to perform simultaneous calls to getVoxel... from a number of threads without locking being performed, but if memory needs to be moved/resized/deleted then that is the point at which an internal mutex should be locked.

I'm no expert in threading though, and I don't intend to implement a volume like the above unless I actually need it myself. It would also make PolyVox dependant on an external threading library, and may impact the single threaded version of the code. Basially, full threading support would need a lot of thought.

I have found message passing between threads to be efficient and easy to use.
There is one thread that manages your volume and the extraction.
Any changes to your volumes are passed as a message containing either a single coordinate and a voxeltype or a list of those or a region and a list of voxel types.
If you want a region to be extracted, you send a message with a region.
once a region has been extracted, a message with the surface is returned.
if you want to read part of the volume it works like setting part of the volume, only that a message with the changes is returned.

now, the fun part would be to create futures (check c++ stl for "future") that simplify the return messages.

the same goes for raycasting, you pass a message with parameters and get back a result.
gets complicated for raycasting with callbacks thou.