Hi,

I was just wondering if there's a way to lower the huge amount of indices generated by the marching cubes surface extractor. DBPro can only handle up to 65,535 indices (or indeed vertices, whichever is greater; is this a common limit for other engines or is DBPro showing its age?) per mesh and that makes for many very small meshes when PolyVox creates so many indices for what appears to be a visually simple mesh. I noticed on one of the older threads somewhere someone said they thought you were using the least efficient format for the meshes.

I know this is bordering on off-topic, but do you know if there's a way, simple or complex (regardless of whether I'm skilled enough to implement your ideas I'd like to hear them), to achieve a smaller amount of indices (preferably without decimating the mesh)?

Clonkex

you could use smaller extraction regions.
it should decrease the number of indices on average

Of course it would, that's what I mean by "makes for many very small meshes". I was wondering if there's a way to decrease the number of indices in the generated meshes (ie by using triangle fan or something) without decreasing mesh quality.

Clonkex

there used to be the mesh decimator, but it was not only removed, David tends to discourage its use since quite some time. It had lots of artifacts when used on marching cubes meshes anyway.

You should find an external mesh library and use some mesh decimation function from there on your mesh.

So this is indeed an issue with older hardware/engines where the indices can only be 16 bits. To be honest I don't know how much of a problem this is in practice, but my quick calculations show that you'll probably be ok extracting a 64x64x64 region but that 128x128x128 is probably too much. Does this match with what you are seeing?

The use of strips/fans may indeed be better but PolyVox doesn't generate these at the moment. It's something I'd like to investigate (along with optimising the mesh to improve vertex cache usage) but I doubt if it will happen soon. I'll add it to the issues list at least.

A few options:

• If you have a large volume then you should already be extracting it as a number of separate meshes/regions, so as ker said you could ensure that your regions are always below the problematic size (though this will depend on the contents of the voxel data).
  
• You could investigate an algorithm to generate strips/fans from lists. I don't know how this is done but I guess standard approaches exist. Anyone know anything about this?
  
• You could manually split the index buffer into two separate smaller ones, both using the same vertex data. I guess this should be pretty easy.

A mentioned, the MeshDecimator has been removed. In Cubiquity I'm downsampling the volume before performing extraction and I believe this a good approach, but there are still some issues to fix.

I can get a 32x256x32 region, but 64x256x64 is too much. As my test I'm creating a random heightmap of the same size as the volume and setting the density of each voxel at the height specified by the heightmap (between 0 and 255) to 255. This results in a mesh that looks like a "thick" heightmap. Of course the number of indices varies greatly depending on the contents of the volume, so there's no "safe" size to always create the meshes.



Smaller meshes = more draw calls. It won't affect performance an enormous amount having the mesh split up this much but I still have to explore every option.



I was hoping you'd know this I'll do some more research but to be honest I have no idea what to search for.



I hadn't considered this. It might help, be I really have no idea how I would go about doing this in DBPro and that's something you can't help with.

Anyway you've given me some ideas, so thanks for that

Clonkex

32x256x32 is the same number of voxels as 64x64x64, and this is the size I use in Cubiquity (I think). It's a good balance between keeping the number of batches small and keeping the extraction time small.



I searched for 'build indexed triangle strips' and found a few links but they all appear quite old:

http://www.codercorner.com/Strips.htm
http://hacksoflife.blogspot.co.uk/2010/ ... strip.html

I believe that 'indexed triangle strips' are what we want (not just 'triangle strips') though the same principles might apply to generating them and you could investigate other approaches.



Well splitting the index buffer should be easy and independent of DBPro. The tricky part is how you can set two index buffers to use the same vertex buffer, but I expect it's possible.

Anyway, I think you should aim to keep your meshes small enough by choosing an appropriate region size, and in the cases that it does go over you could then perform this kind of splitting.

Yeah, I think so. It should be possible, but I really wouldn't know how and I think I'll just go with the simpler solution of smaller extraction regions

Anyway thanks for the links, I'll take a look and see what I can come up with

EDIT: I don't think I've mentioned this before: my real name is also David. David Hynd

Clonkex

On this topic, yesterday I saw the first results of integrating Cubiquity into Unity3D. I ran into the same issue of 16-bit index buffers being used, so apparently it's a problem for modern engines as well (perhaps because they target mobile?).

For now I'll use smaller regions and just drop meshes if they do happen to get too big, but it will need some thought in the future.

Wow, I had no idea Unity used 16-bit index buffers. Well that makes me much more confident about using an older engine like DBPro

Clonkex