Hi all,

Although the PagedVolume (previously LargeVolume) allows the user to create a volume of any size, this size still needs to be specified on volume creation. I feel this is an unnecessary restriction, and that all PagedVolumes should be created 'infinitely' large (within constraints of 32-bit voxel positions).

The idea is that you would create a PagedVolume and provide your paging functions, which work in the same way as at the moment. Any time you try to read or write a voxel PolyVox first ensures that the appropriate chunk exists in memory by calling the paging functions you supply. PolyVox would no longer check that the requested voxel position lies within any prespecified bounds.

I don't think there are any real advantages to keeping the PagedVolume as having a fixed size so I think this change makes sense. It will boost performance and simplify the code, as profiling has shown that the PagedVolume::Sampler is being slowed down by the (surprisingly convoluted) logic which ensures it is always pointing at a valid voxel position.

However, there is one catch. Currently PolyVox provides the concept of 'wrap modes' which work similarly to OpenGL - that is you can specify what will happen when you try to access a voxel outside the volume (clamp, border, etc). This will no longer be possible (at least for PagedVolume, not sure about the RawVolume) because all voxels will be considered to be inside the volume. So, is anyone making explicit use of wrap modes and feels this might be a problem?

The above is just my initial thoughts... I will dig into the code over the coming days so maybe I find a reason why it can't be changed. I'll also be giving consideration to iteration and threading as I review the code.

I'll be honest, I made my own volume definition based on raw volume and threw out all of the border voxel code in it a while ago. All of my functions pre-check if an operation is going to be in volume anyway and I got massive speed increases by running voxel operations straight to the storage with no checks in place when doing mass edits.

So far I haven't run into a situation where I wanted border cases at all.

Thanks for the feedback! To provide some context, the wrap modes were introduced when experimenting with LOD in an early version of Cubiquity. We do LOD by down-sampling the volume, which sometimes required special handling.

I'm not sure if we still use wrap-modes in Cubiquity (I need to check this) but I'd like to move towards infinite volumes there as well. Even if wrap modes are needed they can probably be implemented at a higher level by the user. If the user cares whether a given position is inside the volume then they can perform that check themselves, and wrap/clamp as appropriate in their own code.

That said, I could leave them in, as the samplers could be templatized on a 'PerformWrapping' parameter so that the code can be stripped out by the compiler (in theory...) if it's not used. But this may be complicated and over-engineered if no-one needs them anyway.

Hi guys,

I've just merged the feature branch for this into develop. PagedVolume is now almost infinite (only constrained by range of 32-bit integer) and the wrap modes are gone. Actually it is only marginally faster as it seems there are some other bottlenecks to address, but I'll get to those in due time and the code is a lot cleaner/simpler at least.

In terms of API changes, you will need to watch out for the following:

• The PagedVolume constructor now requires you to provide an instance of Pager - you cannot leave this set to null. FilePager provides a simple example implementation but you will most likely want to provide your own. Also be aware that the second parameter now sets how much memory the volume aims to use, and the third parameter is now the desired chunk size.
  
• Wrap modes are removed from both the PagedVolume and RawVolume, and no longer make sense anyway for the PagedVolume as it is infinite. You can no longer set a border value for the PagedVolume, but you can still do so for the RawVolume and this value will be used when you try to access a voxel outside the volume. I'm not certain if this will stay long term but it's still there for now.
  
• The deprecated getVoxelAt() and setVoxelAt() functions have been removed. You should just call getVoxel() and setVoxel() instead.

There may be a few other things but that's the bulk of it.

Thanks allot for this! Unlimited PagedVolumes is reason alone for me to port my apps to the latest PolyVox dev. I mostly use PolyVox for real-time procedural generation and have never had a use case for wrapping.

Hi guys, I just wanted to let you know that I've merged some more PagedVolume optimizations into the develop branch. I've been focused on improving the time to access individual voxels and it's probably something like 50% faster now. This means there is also a performance boost which make heavy use of voxel access. I have some further ideas on things to optimize as well.