Hi all, I'm implementing a new paging volume called TorusVolume.

You can check it out here:

https://gitorious.org/~beyzend/polyvox/beyzends-polyvox

Why?

I need it. Paging into a single volume to get rid of border issues, plus streaming to GPU. Thread-safety is dependent on your own setup, but is possible to generate data in threads.

Example:

It's not done yet but I do have a small example up and running. Still needs debugging. Build and look in {builddir}/examples/torusvolume

keys: left mouse button to initiate movement.
right mouse button to stop movement.

I've updated the demo to simulate a normal app (My own app actually). It does priority queue with page generation being higher priority than extraction. It also uses threading with QtConcurrentRun and futures.

I still have some off by one errors, not sure why. Plus need to also check generation code. After this I will work on the cache proxy. Then I'll be done with this.

Ah, very cool. I haven' been able to try it as I'm halfway through moving house at the moment, and so my development machine is in pieces, but I did have a look through the code (only in a web browser, so it's not so easy to read).

It looks like the code was originally based off SimpleVolume, but that you have changed it so that the data is stored as a single large block? Do you intend to keep it like this, or will you split it up into blocks again? The reason I ask is that the logic changes inside the TorusVolume are fairly small - it seems most of the work is actually done by the PageManager? If the remaining changes could be moved to the PageManager then maybe any Volume type could be used for the underlying representation?

On the other hand, if you do go back to multiple blocks then maybe it is better kept inside the TorusVolume, as you can modulate the block postion rather than the voxel position. But I think we discussed that before, I just forget what the outcome was.

Anyway, great work!

Yes, I had thought about doing a proxy, to work with any kind of volume. Basically all you need is the dimension of the volume and you can page into it using this method, for constant dimension volume. Anyways, I was going to implement a proxy in order to cache the modulation coordinate computation, which is why I implement my own proxy because I thought it would be easier. But sure, I may need to think things through a bit more--write a proxy to wrap any volume. Main reason is I thought doing that it would mean another level of indirection....well I don't have too good of a reason now I think about it. Either way I just wanted to share my clone. Well, actually another reason why I made a new volume class is because I also wanted to support compression in a specialized way. I wanted to keep separate the compression storage and regular voxel storage. But now I think about it, this logic don't need to be inside a Volume class either.

As for the paging manager, it just a simple example. I already have a paging manager in my own game. Wouldn't a paging manager be beyond the scope of PolyVox? I wrote it mainly to test TorusVolume.

Yeah, part of me has been wondering whether a kind of wrap mode belongs in PolyVox. Like OpenGL has clamp, border, or wrap modes when you access outside a texture, maybe there should be something similar in volumes (but for writing as well as reading). The wrap mode would then start to be similar to what you have implemented here. Well, I don't really intend to do it for the time being, and it might complicate the samplers, but it's an interesting thought.