Looking at this post
https://forum.castle-engine.io/t/clear-and-reuse-a-scene/881
may already answer what I was essentially thinking about. I think this is going to come down to testing both approaches. Perhaps making it parameterised - balancing how much is stored per cell against size of cells, against occlusion benefit - according to performance feedback…
It seems that toggling the “existence” of content - without deallocating is a fast operation. But unfortunately a large environment is going to require allocation and deallocation. It will have to be a matter of testing to find at what granularity this will be most efficient, and ways of spreading out the delay to minimise variation in the framerate.
Changing part of the X3D tree means rebuilding the tree.
I’m now wondering about a scheme of keeping everything inside one pre-allocated indexed face set for the terrain. Then reallocating cells and regenerating at different resolutions is a matter of changing vertices and indices in the one static buffer. This would essentially amount to creating a memory allocator to operate in the memory space of an indexed buffer…
But that won’t work with the occlusion culling…
So having a pool of pre-allocated vertex buffers and reassigning them to different cells by changing their vertices and indices inside the buffers? The buffers remain allocated - but they assume the roles of different cells as required by changing their contents - without changing their size?
I need to convert the slow operations of de-allocation and re-allocation of the scene graph to one of repurposing a non-changing scene graph by only using the fast operations of moving the positions of vertices and possibly indices.