I can't really use the Big Volume because I use multi-threading. A few month ago David mentioned scrolling as a way to implement paging, just wondering what you guys/gals think about this.

I'm about to implement something similar (scrolling) for streaming data into textures on the GPU. The idea is to map pages into a single texture with a torus topology. The way my system is setup, I have multiple pages centered around the camera, ex: a 9x9 square. (Each page correspond to a NxNxN region of Volume.) The pages on the outermost border (imagine a castle wall) are prefetched, ie. they exist in memory but are not visible to the player. For any new pages (or any page actually) it's position is relative to the center page, which is the location of the camera. So to map a page into a torus texture--in-place without allocation--we just need to use:



With texture wrapping this will work, because everything is defined relative to the camera, which is also the "center" page. New pages are always paged into the correct page relative to the camera.

...
I was thinking with a small tweak this would also work for SimpleVolumes. Just need to implement texture wrapping for the SimpleVolume. With this we can do paging without allocation. Multithreading would still work (assuming you are doing multithreading the way I'm doing it).

What do you think?

If I get around to implementing this in a SimpleVolume like class I will provide the source.

I think the idea is basically sound, though I'm not sure if it belongs inside the SimpleVolume class. This is because we would still want to support the approach of using a border, and supporting wrapping as well would add extra logic to the voxel access and also to the volume sampler. Also the LargeVolume would need to be modified to have consistant behaviour.

Until the approach is proven it might be best to duplicate the SimpleVolume, rename it to something like ScrollingVolume/WrappingVolume, and make the changes there. Also, rather than using the % operator to wrap the voxel position, maybe you can just use it on the block position? i.e. the voxel position gets split into a block position and an offset within that block. Maybe you can then leave the offset untouched and just wrap the block position. An advantage of this might be that you can contain all the logic within the getBlockAt() (or whatever it is called) function and then it might automatically work for the samplers as well. I'm not certain though!

Oh yes, I was going to make a separate volume class that is similar to SimpleVolume. I will try to make it API compatible to SimpleVolume as much as possible. Also I don't mean % on voxel positions, I was really talking about PageX and PageY. Pages is something specific to my app, but they correspond to blocks. A page is actually just a block, a region of volume. H(x, y) maps regions into the volume.

I was also thinking that perhaps I could get block compression to work. Basically expand the number of blocks out from the camera. Blocks a certain distance away from the center will be compressed. This means new blocks that are paged in are compressed. When they get close to the camera, they get decompressed.

Sure, your compression scheme sounds sensible. You may be able to take some code from the LargeVolume here.