holocronweaver wrote:
I am building an octree based LOD / paging scheme for my procedural terrain. Currently I am using multiple PagedVolumes, one for each octree level, and manually copying data between levels as needed. This is wasteful, both performance wise (due to all the copying) and memory usage wise, but I don't know of a better approach using PolyVox as is.
As I recall, in Cubiquity we do something similar (but copying to RawVolume instead of PagedVolume?). However, I'm making quite some PagedVolume changes at the moment with the intention of moving to a system like you describe. Ideally I want to set it up so that the pageIn() function for a given LOD level would read and downsample the data from a higher LOD level, meaning that no
explicit memory copy needs to be performed (by the user). The user would access a voxel at a low LOD level, and if the chunk didn't exist it would be created from the higher LOD level. Each LOD level would also cache the chunk using the existing PagedVolume caching infrastructure.
I think the above can probably be done already, though I haven't yet tried it in Cubiquity. There is a question of how to invalidate lower LOD levels when a higher LOD level changes, but
I think that the flush() function will handle this.
holocronweaver wrote:
One solution I considered is introducing a step size to Region, which the surface extractor would obey. This would allow a single PagedVolume to store all the octree levels. Low LOD levels would have large step sizes, while high LOD would use small steps. I realize this would weaken cache coherency during extraction of low LOD octree levels (since the step size would be very large), but I believe this will be compensated by low LOD having a relatively small number of voxels.?
Actually we used to do something like this but it made the code rather complicated (particularly at the edges of Regions), and it didn't give much control over how the downsampling was performed. Also, be aware that every voxel gets touched at least once, and often more than once (e.g. when computing the normals, if we are talking about Marching Cubes here) so I think that downsampling ahead of time probably does make more sense. But I do think the Marching Cubes extractor could be improved to make less voxel reads anyway.
Overall though this is a rather active research area in Cubiquity so my conclusions aren't final.