Hi !

Always working on my project, i meet another problem.
Decimator create holes ! It happens randomely on small faces.
I don't have this problem when decimator was called for the whole volume.

This problem appears with the mesh pagination, decimator is called for each mesh (EDGE_COLLAPSE_THRESHOLD = 0.88f).
I see a discussion on the forum about holes, but i am not it was about paginated mesh and it was 2 years ago.

Holes aren't in the intersection of two mesh.

Here two screenshoot :




I hope you can help me

Thanks for help

Do the holes lie on the edges of regions (i.e. where two meshes meet)? It can be tricky to decimate two meshes independantly such that the results continue to line up with each other. The edge vertices are supposed to remain fxed for this reason (as I recall) but maybe there is a problem there?

However, to be quite honest, the MeshDecimator is the weakest part of PolyVox and I wouldn't recommend using it. It remains in the library because there isn't yet an alternative, but I do think it has some issues and is also rather slow.

The problem is basically that PolyVox only outputs vertex and index buffers ready for rendering, whereas effective mesh decimation requires a more advanced data structure such as a winged-edge mesh which contains adjacencey information about a vertices neighbours.

There are basically two approaches which you can consider instead. The first is to replace the use of MeshDecimator with an external mesh processing library. In future versions of PolyVox I expect we will remove MeshDecimator and instead provide an interface for such integration. You may want to check out OpenMesh as one option though I've never used it.

Alternatively, you can consider downsampling the volume data before running the surface extractor. The SmoothLOD example is a little messy but does demonstrate this.

Note that the above discussion only applies to Marching Cubes meshes. The CubicSurfaceExtractor has very good decimation built in, so there's no need to use anything external.

As i say, "Holes aren't in the intersection of two mesh."

I use the recommended release "PolyVox-GIT-2e4bf67.zip (11th December 2011 – Recommended)"
Is it possible that a earlier revision will correct my problem ?

I will try find some library in parallel.

I have just tried the Ogre::ProgressiveMesh to use the LOD system to create decimated mesh.

Polyvox decimator generate better mesh (ProgressiveMesh = odd faces).
Meshes generated with ProgressiveMesh don't fit together perfectly...

Sorry, I obviously didn't read very carefully

No, I don't think an earlier version will help.


The problem with using the Ogre ProgressiveMesh is that it won't understand the input data properly. For example, I would expect that Ogre decimates the mesh based on certain properties such as the position of the vertices and their texture coordinates, but with a PolyVox mesh you also need to consider the material identifier so that you don't combine two vertices with different materials (though I realise you haven't started playing with multiple materials yet).

Ogre::ProgressiveMesh also won't understand that the meshes are meant to fit together, so it won't know that it has to exactly preserve the boundaries of the mesh (or at least, any changes it makes also have to be made to neighbouring meshes). This is probably why they don't fit together.

If you use an external decimation library then it will need to be configurable, so that you can express the the kind of properties described above. I don't know how well OpenMesh will fulfill this criteria but it will be investigated in the future.

Unfortunatly the decimation of voxel terrain meshes is really an open research area so I don't think you'll find a solution that just works 100%. It might be better to downsample the volume data (like the SmoothLODExample) but this hasn't been well tested, and will have it's own set of problems with multiple materials.

You might also find these blog posts interesting as they describe some of the reasons why this problem is difficult:

http://0fps.wordpress.com/2012/07/21/simplifying-isosurfaces-part-1/
http://0fps.wordpress.com/2012/08/20/simplifying-isosurfaces-part-2/

I have tried OpenMesh : it is not user friendly at all... A simple conversion from its mesh representation to an Ogre::ManualObject is a pain.

The SmoothLODExample uses some new stuff unavailable in the official release.

I think the problem with the PolyVox decimator is about the extracted meshes which are not closed volumes but a part of it, not closed so.

In my brief look at OpenMesh it looked fairly complex (heavy use of templates) but also very configurable. But I haven't used it so I can't be sure it's the right tool for the job. I hope in the future to add some utility classes to PolyVox wrap/simplify the OpenMesh usage but it's not going to happen soon.

I'm sorry there's no easy solution for smooth terrain LOD in PolyVox... we do need to do some work here but it's also not clear what the answer is. It's kind of an on-going research area. You might just want to try getting by without it until we have something better.