I believe it has been touched on here and there but I believe I have a scenario which would call for the use of multiple volumes.

If I wanted to represent two large spherical worlds as voxels, in a static environment, I would create one very large volume to encapsulate both worlds and this would work great. You could easily find which voxel your trying to manipulate etc..

In a dynamic world, where each planet in the 3d environment were rotating on it's own axis, rotating a central point, and doing each of these at separate velocities. It would make sense to hold each world in it's own volume. The key reason why I feel this is a good approach is because each world will be so far apart that there is no chance they could interact with each other.

So I am asking for your advice here, would there be a better approach?
Thank you for your time!

_________________
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 absolutely possible. Have a look at this recent video we made for Cubiquity: http://youtu.be/NLQozqoPMho

The idea would work in any PolyVox-based application though. The main things to watch out for are picking (which needs to handle multiple spaces) and triplanar texturing (don't texture in world space or textures will slide across moving objects). But the basic implementation is not too difficult. Just ask if you have any specific questions about this.

Okay awesome thank you! I wanted to make sure there were no issues with using multiple volumes. Thank you again!

_________________
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.

I am using multiple volumes in my terrain chunk-based system, without any problems.

the only complication is if we need to make marching cubes meshes line-up, but I solved this via overlapping of chunks data, and extracting the meshes without borders, e.g. if chunk size is 16x16x32, the volume size is (-1,-1,-1 - 17,17,33) - I fill borders of different chunks with same values but use extractors at (0,0,0, 16,16,32) so they line up.

Actually it isn't recommended to use multiple volumes for creating chunk based terrain. It should only be used for the 'seperate planets' scenario which kklouzal describes. You can read a bit more here: http://www.volumesoffun.com/polyvox/doc ... l/FAQ.html

How big is you environment in voxels? The LargeVolume doesn't work well with threads (as discussed elsewhere) but even the SimpleVolume should handle a hundred million voxels. It won't get you infinite terrain though, but maybe you can work with it until we get a better thread-safe solution in place.

Yes, I already read that post. It's not difficult to handle the implications of this design.

Yes, I have some data duplication - the border cases - I overlap the datasets, so we get nice seamless matching meshes.

I invested two days to make it work like that and I am going to never touch this code again, because it's just working now. Threading, seamless Marching Cubes Smooth geometry and... a lot more big terrain than a LargeVolume (this is, we may have max_int x min_int chunks and not voxels).
Still, it's not a trivial task to do, but when it works, I'm happy.

Watch out for lighting though - for a given vertex PolyVox looks at the nearest two voxels, and then uses the neighbours of those to calculate normals via 'central differencing'. I think you will need an overlap of two voxels to avoid lighting discontinuities in this case (but maybe I'm wrong - I didn't test it).

To avoid this you should probably discard the vertex normals from PolyVox and compute them yourself, probably by averaging together the normals from adjacent faces. Well, just keep it in mind if you see these problems.

Thanks. Normals were totally broken with 1 px overlapping.

But thee case is different with 2 voxels overlapping: Seamless!

That looks pretty nice! The two-voxel border means that it will be harder to update a voxel because you will have to update it in multiple volumes, but if it is working for you then great. You still have the option to switch to calculating the normals from surrounding faces in the future if you want to. Look forward to seeing where you go with this!

I already handled all cases from within the Chunk Manager - the case with 1 chunk, 2 chunks and 4 chunks update.

Anyway, I'll post in the "Showcase" forum soon, because I hate stealing / hijacking topics and I feel like I am doing this right now