Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

Paging Volume (Previously: Streaming Volume)
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=2&t=145		 Page 15 of 15
Author:  Shanee [ Sun Apr 03, 2011 5:23 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Author:  David Williams [ Mon Apr 04, 2011 9:54 am ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Author:  ker [ Tue Apr 05, 2011 10:19 am ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Author:  David Williams [ Tue Apr 05, 2011 8:28 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Author:  David Williams [ Tue Apr 05, 2011 11:57 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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 :)
Author:  ker [ Thu Apr 07, 2011 8:44 am ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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 :)
Author:  David Williams [ Thu Apr 07, 2011 5:52 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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).
Author:  David Williams [ Sun Jul 31, 2011 8:56 am ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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?
Author:  ker [ Mon Aug 01, 2011 10:03 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Author:  David Williams [ Tue Aug 02, 2011 8:16 pm ]
Post subject:  Re: Paging Volume (Previously: Streaming Volume)
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.
Page 15 of 15 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/