Ok I think I see where I was wrong. I think I have been a little hard-headed. Lets see if I get it now.

If I provide the function overloads that Largevolume requires, then the rest of the paging is transparent to my program. I simply request data to be extracted and stop extracting other areas and the paging happens automatically behind the scenes. This is provided my overloaded functions work correctly of course.

I think this is what everyone has been trying to tell me. If not please correct me.

Now I need to figure out the region concept, at least how it applies to the new LargeVolume. I will need to read the documentation and forums before I ask any questions though.

Thank you for your help! You have been most patient!

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

Yeah pretty much..... it's a good place to start, anyway. Later once you are more familiar you will probably find you need to move paging into a separate thread which would require some changes.

As for Regions, LargeVolume only requires one if you are using the large, fixed-size volume. The constructor for the paging volume takes no region parameter.

Apart from that, regions will be used for mesh extraction.

Do you mean write my own paging engine? or make the overloaded function create a thread?



This is what I was referring too. How I either define or discover the bounds of a region for mesh extraction.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

Defining region bounds for mesh extraction is entirely arbitrary. In my case I have my world broken up into a series of 32^3 cubes, which I use for both paging and mesh extraction. To manage extraction and paging in different threads, you will need to do a bit more work yourself.

Eg in my code, my paging thread checks the cameras position and determines which chunks should be active based on view distance. If those chunks are not allocated, it flags them as needing to be allocated/loaded. The list of chunks needing allocation is checked by another allocation/loading management thread, which interacts with polyvox to allocate the necessary blocks, then uses setVoxel so set voxel data, and finally marks the chunks as active for extraction. I use listeners to alert the mesh manager that updates are required whenever a chunk is set active, or voxel data changed. Finally a mesh management thread checks the update list, extracts the meshes required, and attaches them to the scene using the ogre scene manager.

All of those classes address chunks with 3d int vector, and since chunk size is constant, the region to extract, coordinates of node to attach the mesh etc are easy to calculate and consistent. Eg for chunk 0,0,0 I extract region 0,0,0 to 31,31,31. Or for chunk 10,10,10 I extract region 320,320,320 to 351,351,351 for example. Keep in mind vertex coordinates are relative to the lower bounds of the region, so the scene node the mesh attaches to also needs to have same coordinates as minimum bounds of the extraction region. Your coordinat system will have to change a bit if you are using 2D paging (which most people seem to be?), whereas I page in 3 dimensions.

This might not make much sense, it is a simplifcation of what I really use. My pager tracks multiple positions simultaneously, and I actually have a VolumeManger, ChunkManager, MeshManager, Pager, VoxelDataLoader, VoxelGenerator, GarbageManager, and I run 6 threads, not 3. Also I use dedicated threads, not task based threading. So I might have screwed up my explanation a bit.

This may be stupid question, but I'm curious. What happens if the camera wanders into the negative quadrants? if your region is -31,-31,-31 for example, can polyvox handle negative region coordinates for extraction?

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

This shouldn't be a problem - negative coordinates should be handled properly.

The only change would be if you are managing paging externally, the calculation to find block coordinates from voxel coordinates changes slightly for negative voxel coordinates

if(voxelCoordinates.x < 0)
blockCoordinates.x = ((voxelCoordinates.x + 1) / mBlockSize) - 1;
else
blockCoordinates.x = voxelCoordinates.x / mBlockSize;

.. and so on.

The calculation for minimum/maximum voxel region coordinates for the block do not change.

Hey to turn world coordinates into block coordinates you can also do:

x = floor(world.x / block_size)

Because floor truncates towards negative infinity so it works out for negative numbers.

Oh yeah didn't think of that. Thought I was missing something obvious.....

I'm not sure which one is faster though. Default floor can be pretty slow. Not sure how much "fast math" improves it either. But I think until optimization stage it probably won't matter that much.