I'm not sure why there might be need for 20cm, but hey, it's still possible I guess.

PolyVox would need LoD though :/ (DAVID!!!!!!!!!! )

what do you mean by lod?
just for distance drawing (which currently has the issue of holes)? or being able to split up a voxel into a small volume/block? (or both?^^)

level of detail.

Let's say our normal mesh is highest detail level, then for meshes far away we want to save on triangles (less detail) to save performance. yep, for distance drawing then.

What holes problem? thought there is no LoD implemented in PoylVox at all.

not really, but there have been experiments going on in this forum...
the holes happen on the border between between the different quality meshes.

very common problem in any lod system in the demo I posted we used skirts, heightmaps are easier than voxels though.

Thanks for the new patch. I actually have another request - maybe this is too fiddely but it would make my life a bit easier...

Basically it seems there are three seperate features which have been included in that patch:
1) Support for 32 bit positions
2) Support for signed position
3) Support for streaming volumes

As some examples are breaking it would be really useful to apply the features one at a time, get each one working properly, and then move on to the next one. Actually, featues 1 and 2 are so closely related that thay can be done together, but it would be really helpful if 3 was a seperate patch (especially as this one needs boost).

Any chance you can send just 1 and 2, I'll make sure the examples run properly, surface extractors work, etc. I'll also check it with Thermite and then commit these features. Then we can handle the streaming seperatly?

sure I can do that... but it's really confusing to create something like "int32_t getWidth()" ... you won't be able to access negative coordinates without streaming (or internal remapping)

So you mean even if the interface and algorithms are modified to support large signed positions, there is no way to effectively test them without the streaming support? I do agree with that, but I think it's still useful to seperate tasks 1 and 2 from task 3 if possible.

Then the process can be:

• Apply support for large signed numbers, but only test with small unsigned numbers. Make sure everything works.
• Add streaming. Test with only the same small unsigned numbers as before, and make sure everything works.
• Test with large and/or signed numbers, fix any problems

I think the large/signed changes (tasks 1 and 2) might as well go in together (I can imagine iit would be difficult to seperate these) but if the streaming could be seperate that would be handy.

Don't sweat it too much if it's too difficult - the contribution is always appriciated anyway. I'm just trying not to break too much at once...

I'm almost done with large signed numbers, but yes, you just won't be able to test it properly... I can actually create the streaming without streaming as a half-step to allow negative numbers if that would help (basically don't implement any streaming, but use unordered map or remap the indices in getUncompressedBlock to positive values but invisible for users of getUncompressedBlock

I would say it best to keep it simple (without the half streaming). From my point of view I'm mostly concerned about not breaking existing behviour (or at least understanding what has broken). The testing of the new features will mostly be down to you as I don't have a proper project making use of it.