What data does LargeVolume page?

From a cursory glance over the code, LargeVolume appears to only page volume data. The surface is extracted anew each time, with no buffering of mesh or other data. Is this correct?

If so, Marching Cubes must be faster than I originally thought because after initially loading a 128x128x128 volume, when I return to it later the surface only takes a fraction of a second (~0.5-0.75 s) to finish extracting. This seems too fast, so I am guessing preservation of triangle data is occurring at some level and I am missing it. Is the PolyVox implementation of Marching Cubes really so good that the only thing buffered during paging is volume data?

I am travelling at aircraft speed high over my endless terrain and I never notice popping or stuttering while paging.

specs:
Intel i5-2550k
AMD HD 6950

Yep, that's correct, it's just that fast

Ok, to be honest I don't know how fast this is compared to other Marching Cubes implementations. I believe ours is fairly decent and it uses some nice tricks to speed up the processing of a given cell. But there's no SIMD or space skipping structures, and it also works best on smaller regions rather than larger ones (I think?).

I have thought about a mesh caching system but not as part of the large volume. My idea would be to compute a checksum or hash of a given region and then check whether we already have a mesh with a matching checksum. This might be at a higher level than PolyVox though, and I haven't really thought about it in detail.

Since Marching Cubes is so fast, I am not sure mesh caching is even necessary. However, after seeing the terrain work done by forum user GM_Riscvul which performs mesh caching outside PolyVox, I might try caching the mesh as an optimization. However, I see no reason triangle caching shouldn't be added to LargeVolume as an option. This allows maximum user laziness.

I don't think that any caching system would need to be specific to the LargeVolume, and perhaps it shouldn't even be restricted to meshes. For example, rather than downsampling a volume for LOD purposes you might be able to reuse a previously downsampled version. Or existing ambient occlusion results? These would again rely on some kind of checksum on the original data.

I had not considered a generic caching system. Sounds like a great idea!