CloudCompare forum

Yes, that's it. And for the 'volume density' we simply divide the number of points by the volume of the sphere (while for the 'surface' density, we divide it by the surface of the equivalent circle).

It is not clear to me what the problem is exactly, but I would guess that there's one point that has a totally different distance from the rest. This make me thing about a 'limitation' of the C2M that was fixed recently in version 2.13.1 version. Can you test with this new version and report here if...

Voici ce dont on a discuté par email (pour continuer le fil ici): Quelques commentaires : - si c'est plus simple, ou si le trou n'est pas rectangulaire, vous pouvez aussi utiliser l'outil 'ciseaux' (Edit > Segment) qui permet de découper selon un contour - utiliser un mesh (OBJ) aurait l'avantage d'...

So the Connected Components tool uses a simple 'connected components labeling algorithm' applied to a regular grid. And we simply use the cells of the cloud octree considered as a given level of subdivision to convert the cloud to a grid. The octree is a recursive subdivision of the cloud in 8 cubes...

Well, it all depends on the memory your PC have. As long as the individual scans don't contain more than 1.5billion points each, CloudCompare can normally handle them.

Bonjour, Au contraire, a priori si le nuage est assez dense, il vaudrait mieux utiliser l'outil '2.5D Volume ' ( https://www.cloudcompare.org/doc/wiki/index.php/2.5D_Volume ). Celui-ci ne marche qu'avec des nuages. Après il 'suffit' de faire la différence entre les deux nuages, selon une direction p...

See https://github.com/CloudCompare/CloudCo ... .cpp#L9095

I would guess that there's an issue with how the normals are oriented. How have you computed them?

You simply have to check the 'Visible' checkbox in the options:

Yeah, Canupo should work great. What parameters are you using? (maybe you could share a screenshot). Have you used very/too large scales maybe?