Would be simple to just have SetVoxel set the boolean to true. Then yeah, just don't call the function or let the user decide.

Yes, I agree it's probably that simple. I'll try to take a look at it when I'm back at my dev machine, but I do want to get the RLE stuff merged first.

I'm actually doing this outside of the volume class in my game, since I have much more info per chunk than just a bool indicating the chunk has changed.

I'm not sure if this should be done inside the volume class, since there are so many things the volume class could also do, but that would make it way overpowered for many users.
In my code I wrote a wrapper class that takes care of such things.
Maybe a few wrapperclasses would make sense. They would be friend classes of Volume and therefore able to perform such things much faster than custom classes, but they would not extend the volume class.

Yep, I'm defintely in favour of keeping the Volume class as simple as possible, at least until it has had more testing. Wrapper classes are also possible (for example, in PolyVoxUtil there is a VolumeChangeTracker which is a kind of wrapper. Don't use it because it's pretty broken and will probably be removed, but it illustrates the point).

On a related topic, I'm currently make merging the RLE branch into the trunk. Should be done within the next couple of hours.

Ok, this has now been merged into the trunk.

I've started a new thread here to make sure people are aware of the changes and to deal with any problems which arise.

Thanks ker for you help

great!
This thread should then better be closed.
I'm gonna wait for the git release before I play around with it further, currently it works just as I need it thou

Actually I think we can leave the thread open. If there is more development in this area in the future then we might as well tack it on the end of this same thread. We can use the other thread for any problems which come as a result of the merge (which contains more than just paging).

I'm making some more changes and would like anyone's opinion (espesially ker's) on how this might affect the paging and/or compression in the LargeVolume.

PolyVox already provides the concept of Sampler's within each Volume type. These are used to provide fast, read-only access to a voxel and it's neighbours. Retrieving a voxel though the usual Volume::getVoxelAt() function requires some maths to compute the voxels location in memory, whereas a voxel sampler caches this information. Moving a voxel sampler only a small distance within the volume is very fast as it has knowledge of the volumes internal structure, and looking up neighbour volumes is also very fast.

I am proposing to allow Sampler to write data into the volume as well as read data from it. I have been working recently on code which copies data from one volume to another, and may also resample, blur, or otherwise process the data. It would be nice to do this by setting up two samplers (one on the source volume and one on the destination), move them in syncronization, and copy data directly from one to the other.

I have identified one problem with the LargeVolume, in that it uses a flag called 'm_bIsUncompressedDataModified'. If a block is decompressed but never modified, then this flag is used to determine that the block does not need to be recompressed as it hasn't changed. Writing directly to memory through an iterator will bypass this mechanism. This can be fixed by either removing this flag (and compressing every time) or by having the iterator set the flag.

Can you think of any other problems which might occur as a result of this change?

As long as it is assured, that there is only one sampler per volume, it should be safe the way you propose it.

Obviously reading in the volume will cause more compression calls now, but in my tests the compression never actually caused any problems since it is really fast (as in way less than a millisecond for a full uncompressed buffer of 64^3 blocks, thou I don't remember what buffer size I had)

As an alternative, you could "touch" (setting m_bIsUncompressedDataModified to true) the block whenever the writing-access-sampler loads that block. this would basically emulate the behavior of the regular setVoxelAt function without requiring any additional modification of block or LargeVolume, but not causing additional computational effort during most iterator movements.
of course, if you're not writing after every move, you might touch some blocks that you didn't modify. Read-access won't change behavior this way, so I think you won't need to worry about problems.

This is a good point, but now that you mention it don't we have this problem even with the read-only sampler? If one sampler is pointed at a particular block, then reading from somewhere else in the volume via a different sampler can cause that block to become unloaded and the sampler becomes invalid?

Actually it's worse than that... even with one sampler it can become invalid if the user calls the getVoxelAt/setVoxelAt directly on the volume. I think we overlooked that

I think maybe the volume needs to keep a list of samplers which are pointing at it, so that it can mark them as invalid them if necessasary.



Yep, we will have to do one of the above. I'll pick whatever is easiest (probably removing the flag) but it's an internal implementation detail so we can change it as indicated by profiling.