Wow, this is getting interesting, but let's just check my understanding. Rather than really extracting a mesh in the way the PolyVox does, you are starting at the top of the octree and checking if the root not is copletely solid. If so, you simple draw one large cube. If not, you go down to the next level and check each of its children. So rather than extracting a surface you are simply drawing cubes of different sizes?
I considered something similar before I built decimation into the cubic surface extractor. In my case, the idea was that I would find a solid shape in the volume and find the largest cube which would fit inside it. I would then find the largest cube which would fit in each of the peices which was left, and so forth. Like you, I would then end up with a number of variably sized cubes to draw.
In my case the tricky part was creating an algorithm to identify these largest cubes, but using an octree means you have this information readily available.
DefiniteIntegral wrote:
Since I am still re-extracting the entire domain every time a change is made, once the scene becomes complex making changes becomes very slow.
Not 100% sure what to do about that yet. I would like to avoid breaking the scene up if possible since I don't want to increase batch count and create seams. I wonder if mesh decimation would help (since would mean won't have to clear/create such large vertex buffers each time)
How about just drawing the cubes individually using instancing? This thread (
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=57693) demostrates how you can draw 300000 cubes at 60FPS by expanding points in the geometry shader. Of course you still need to perform updates as your structure changes.