ker wrote:
As long as it is assured, that there is only one sampler per volume, it should be safe the way you propose it.
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.
ker wrote:
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.
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.