CloudCompare forum

This tool is accessible via the 'Edit >> Mesh >> Measure volume

Measures the volume of a closed mesh.

This tool can find any solid (closed) mesh volume and luckily gives warnings if mesh is open (has holes) or has non-manifold edges
For example

[19:27:54] [Mesh Volume] Mesh 'Mesh': V=6.15324 (cube units)
[19:27:54] [Mesh Volume] The above volume might be invalid (mesh has non-manifold edges)
[19:28:36] [Mesh Volume] Mesh 'Mesh.section': V=5.60789 (cube units)
[19:28:36] [Mesh Volume] The above volume might be invalid (mesh has holes)

Unfortunately if closed mesh has flipped normal, this tool can give wrong volume result without any warnings
It is not easy to scan with eyes hundreds of mesh tringle color to check if one has flipped normal
Even Edit >> normals >> compute does not correct normal (I have to use Blender or FreeCAD etc)
Any suggestion?

attached 3 files - Real volume is (8)+(0.99)

Well, meshes are clearly not CloudCompare's forte ;)

More than the normals, I guess it's more due to the order in which the vertices are described? (it will also change the normal sign if you compute per-triangle normals for instance).

In your case, are the normals (visually) properly oriented? (if they come from an external source). Or are you computing them with CloudCompare?

I guess it's more due to the order in which the vertices are described?

You are wright
If we change vertices order , this will happen

This happens when complex mesh is generated by CC ( vertices are in order (OK)) then must be processed -for some reasons- by external software Blander then (some times vertices are NOT in order)
then it is opened back by CC for further processing
fortunately, I found that BLENDER can solve this by ( alt+n >> recalculate outside )

We cannot avoid that some times vertices are NOT in order , so CC has to recognize this issue solve it or at least gives warnings
I think Edit >> normals >> compute depends on vertices order to recalculate normal this is why it fails
Any idea to enhance this compute algorithm?

Attached 2 simple STL ASCII file to show this issue
Exchanging vertices( line 4 with line5) will change normal without any chance that CC recalculate normal correctly

This 'direct vertex order' is normally a convention. And the volume computation algorithms, just as the normal computation algorithm, assumes all triangles are properly 'oriented' (mind that this algorithm doesn't use the normals, just the vertices).

Of course finding flipped triangles is possible. I guess any motivated contributor can do it ;). I'm personally not sure to see the point of duplicating the effort in CC since there are much better tools to process meshes (Blender, Meshlab, etc.). But such a contribution will be welcome of course.