Yep, it's just gone in, You can now call setCompressionEnabled(false). From my point of view I now happy with the features. I'm going to make your example into a seperate 'PagingExample' and revert the Basic example back to it's previous state. Then write some documentation, and then I think we can merge back to the trunk.


This is an interesting question. This sounds a bit abstract, but as I see it the paging mechanism isn't intended as a way of loading data into the volume (although I accept it can be used for this). In your case I would say that the whole world exists in the volume at all times, it's just that parts of it are being cached in memory for faster access.

I'm not sure if I'm talking sense here I'm just trying to decide what are the right concepts. But on this basis, I might ask why you want to force part of your volume out of memory. If it's because the application is shutting down and so you want to save any changes, then remember you can still access all the data (whether it's in memory or not) using Volume::getVoxelAt().

Ok, but dispite saying that I can see it would make users code simpler if they could force-unload, as they can have all their saving code in one place. And it's quite a simple feature to implement.

Actually, can't you just call setMaxNumberOfBlocksInMemory(0) to achieve this?

As for force loading, yes I agree. This is a useful way or warning the volume that you are about to use a particular part of the volume and it should be ready for it. It can take a region, compute which blocks are inside it, and simply call getUncompressedBlock() on each. You want to implement that?

both force unloading and force loading are not for the actual representation of the world, but for performance.

about force-unloading:
you unload a few blocks by position (which is significantly faster than by timestamp)
then when loading new blocks there will be no necessity to find the least recently used block.

a scenario where this would be useful is when you want a region around the player to be loaded at all times.
once the player is detected to have moved so far that new blocks needs to be loaded, he'll also have moved so far that you know what blocks you can unload because they are far away.
if this could be done inside the volume class, it would not only be extremely fast (only accessing the block map by key) but it would remove many many unplannable calls to the overflow handler.

I currently have no clue if that is a good way to do this or makes sense from a game-perspective, but it might be necessary in the future when we're playing around with performance settings.

Ok, I'm convinced, these both make sense. What shall we call them? Because I see the data in memory as a kind of cache containing the most recently used part of the volume, I think the terms 'prefetch' and 'flush' make sense?

yes, flush and prefetch are perfect. Once you have committed your latest changes I can implement them.

Been watching this thread for awhile now - Real nice work guys!
I might, however, just note that some updated documentation might be required as I've had trouble understanding the new method.

hehe very good point...
the paging example (current svn basic example) shows how it's used.
the volume class will obviously be documented (I believe to remember David saying it's the best documented class of polyvox and I'll do my best not to let my changes stop that from being true)
but a small tutorial or two in the wiki shouldn't be too much work either.

Yes, documentation will be important - I have a go at it at the weekend. This is basically the core class of PolyVox so I'll try to keep it detailed.

I've just deprecated the original constructor which took a width, height, and depth. The problem was there is a new constructor taking two pointers and a int, and unfortunatly C++ will happily cast between ints and pointers meaning the wrong constructor could easily be called. The original constructor will now assert and/or abort, so if you want a fixed size volume you must pass in a Region.

@ker - I think I'm done for now so I'll hand it back to you do implement the flush and prefetch.

Oh, and I renamed your example to 'PagingExample' - in case your wondering where it went.

I found something in the Volume-class...


well that depends on what this function is supposed to do...
in setMaxNumberOfUncompressedBlocks you simply unload your whole cache...
why not do the same here? (in case the number is decreased, otherwise it doesn't matter anyway) this is a "cache", too
for me any solution is fine, I set the number once on startup and never again

and another thing from getUncompressedBlock:



I have been thinking about this.
Since now there is a ConstVolumeProxy... this is now really simple, just give the block to the ConstVolumeProxy and remove the evil-setVoxel-const-function from Volume.

I just had no Idea how to do this before you came up with ConstVolumeProxy.