Hey, I'm posting from my phone so can't write much (more tomorrow night). But in summary...

The correct way to fix the seams is to have a single large volume, anything else will have other problems. Note that you should still generate multiple meshes (so you only have to update those that change) which you can do by passing a Region to the surface extractor.

I will add support for much better volume compression (hence large volumes) soon (it's next on my PolyVox list) but it's infinite volumes which i'm not so sure about. I'll have to see how hard it looks once the larger volumes are in.

I haven't looked at the C4 approach in detail (though I saw it as Eric Lengyel edited my article for Game Engine Gems), but my understanding is it simply provides a way to provide seamless transitions between lod levels. This is definitely cool, but not your current problem. it could probably be implemented as a new surface extractor but I have no plans for this at the moment.

Okay, I'll give the one large volume with multiple meshes approach a try. The main difficulty with what I want to do is making a LOD system, since there isn't a way to sample at a lower resolution for further away volume data the way C4 does. This means clients have to have the entire full resolution volume in memory to draw far away terrain data . I think modifying Polyvox to use some kind of octree structure for the volume would make it possible, although I guess RLE will be a decent stopgap.

Ok, I can expand on my previous answer now...

PolyVox treats the representation of the volume separate from the surface extraction code, meaning that more than one surface extractor is available and other volume representations can be added in the future. I think it's useful to keep this distinction when looking at improvements which can be made.

Focusing on the volume representation, the biggest problem is currently the rather poor compression rate. This isn't completely accidental, as one of the advantages of keeping the data largely uncompressed is that it can be modified very quickly without needing to decode any complex data structures. However, the memory quickly gets but of hand and it's clear people want much larger volumes.

My proposed solution is to scrap the block sharing mechanism and implement a simple, fast, RLE compression of the blocks. However, I will keep a pool of recently used blocks (perhaps 10 or so) in an uncompressed state, because if they have been written to recently then there's a good chance they will be written to again soon. This can all be done without modifying the Volume class interface, and I intend to implement something like this in the next month or so.

The next step (which is what you really want) is to allow blocks to drop out of memory completely, so that you can have infinite terrain with only the nearby part in memory. This probably will need some changes to the Volume class interface, possibly so that some callback mechanism can be implemented to allow user code to provide data in the case that it is not in memory (possibly be reading it from disk, maybe generating it procedurally, etc). It's probably not that hard to implement, but may need some experimentation to find the best approach. Unfortunatly I simply have no need for it at the moment as I'm not expecting to work with volumes of more than 1024^3 or so, and I do have to prioritise work based around what I will use/test.

You also mention using an octree - this is of course a good structure from the point of view of data compression and for obtaining lower resolution data for lower LODs. The down sides are that it's probably slower to modify as changes need to be propergated up the tree, and also it is slower to access neighbouring voxels of the one you are currently in (as the neighbours may be in a different node). This last property is important because both the marching cubes algorithm and the surface normal calculations rely on accessing neighbouring voxels quickly. Overall the octree might be a good choice of data structure but I'd need to experiment to see how these different aspects balance out.

Moving onto the surface extraction, I did actually experiment with generating the surface at different LOD levels in the past. It's possible to do it at the moment by keeping a second volume at half the resolution of the first one, and simply running the surface extractor over it as usual. The problem is that there are usually seams between the high resolution mesh and the low resolution mesh. My understanding of Eric Lengyel's work is that he resolves this by examining both volumes at the same time whilst performing the extraction - i.e. you need both the high and low resolution data in memory at this time, so it's not particularly a memory saving technique. But it does fix the seams between LOD levels in a very elegant and robust way.

I should say that I haven't read Eric's thesis, my comments are just based on skimming it and the discussions I have read about it so appologies for any misinformation. It's also worth noting that Eric said he plans to release his lookup tables at some point in the future:

http://www.gamedev.net/topic/591926-mar ... try4753715

If he does so then it could well pave the way for his algorithm to be implemented in PolyVox.

Right, I've written a lot. I hope I don't sound to negative, you raise some excellent and interesting points and describe some features which I would like to implement. It's just matter of limited time and prioritizing what I work on. I'll update the Wiki todo list with some of the things mentioned above.

Thanks for the in depth reply, I actually found the pdf in that very thread, haha. I hope he releases the stitching lookups soon, that would be great. From what I can gather, his stitching process requires the simplified marching cubes method be used to avoid edge case problems in the generated geometry, so even with lookups it would require rewriting that as well. The benefits seem worth it to me, though.

Nice to know, thanks. Also, it's awesome that you have all these plans for PolyVox and Thermite, I'm glad I found your lib.

What do you guys think about Sparse Voxel Tree. Seen the Nvidia demo. What about Gigavoxel tech? I know these are probably not good for dynamic editing, though.

You could still use such a system for more distant terrain and keep local/recently edited stuff in a faster structure for real time editing, I think. That way you get the best of both Actually implementing it is another story, though, I couldn't find any actual code outside of the GPU-centric nvidia paper.

I think the Sparse Voxel Octree stuff has a lot of potential, and is currently poised to be the future of voxel rendering in games. The NVidia demo is very cool and I really like the idea of unique geometry everwhere with the lighting baked in at a high resolution. That said, it's very static, taking many hours to preprocess the scenes in their demo.

Gigavoxels/Atomontage also look very good, though I'm hesitant about technology when there isn't a demo available. I mean, I do believe they work, and I believe they are very cool, but without a demo it's hard to know what the shortcomings of their approaches are.

While I think SVOs may be the future, I also think that PolyVox has plenty of time left. John Carmack has (to my knowledge) abandoned his plans to use SVOs in id Tech 6 which means that id Tech 7 is the earliest they will be used (by id software at least). id Tech 5 is out this year, so I think that id Tech 7 is at least 5 to 10 years away. Then there's the increasingly popular mobile market which will be 5-10 years behind.

That said, I would certainly be interested in playing around with Sparse Voxel Octrees and GPU rendering. Maybe as a supplement or eventual replacement for PolyVox. I don't think I'll be doing this within the next couple of years, but will keep an eye on developments...

Eric Lengyel has released his lookup tables I've split off the thread here: http://www.thermite3d.org/phpBB3/viewtopic.php?f=2&t=139