Hello all! Long time no see.

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.

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.

Any thoughts on this approach? Is there a better way to build an LOD voxel octree using PolyVox?

Modify the Marching Cubes or the Cubic extractor to manually iterate voxels with custom stepping and interpolation. Note that interpolation is also slow but works kind of a good
The best is, PolyVox is open-source

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.



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.

For real-time procedural generation I avoid sampling at high resolution as much as possible since voxel data generation is expensive. Thus I work in the opposite direction: I use low LOD data to partially fill in high LOD data. However, by itself this would not be effective since PolyVox is unaware that low LOD data has already been filled in, so during pageIn requests I have to skip voxels which the low LOD has already defined. This tedium is only worthwhile when the difference in resolution between LOD level is significant, which in my case it is. It would be great if PolyVox had a 'smart region' that only requested the grid points that aren't defined, but I realize this might not be efficient since it implies a boolean for every voxel and may have a small user base.


As you say, voxel data modification is tricky. I currently perform the same volume transform on all voxel LOD levels, starting first with those that are visible. I may try copying changes to non-visible LOD levels if this is too slow. I need to experiment more with making modifications at different LOD levels, but currently my simple-minded approach is pretty fast in my case.

Sorry for the slow reply - I had a busy week.



How are you doing you generation? I can imagine that if you are building terrains from multiple octaves of procedural noise, then the low LOD volumes might only include the lowest frequency octaves, and higher LOD would then add higher-frequency octaves on top of this. So in this sense you can derive your higher LODs from your lower ones. But probably this doesn't work with other approaches to procedural generation.



So basically every voxel would be created on demand (fine granularity) rather than whole chunks at a time (course granularity)? I think there would indeed be some significant overhead to this.

Also, keep in mind that it is possible to define custom volume types in PolyVox. The 'TestVolumeSubclass' test shows how to wrap an array to look like a volume, and the same principle can be applied to wrapping a procedural noise generator. But then you don't have the caching behavior of the PagedVolume, so I'm not sure if this is useful/desirable in your case.