CloudCompare forum

You could maybe fit a circle on each section, the compute the distance of the points of each section to their respective circle entity (with 'Tools > Distances > Compute Cloud/Primitive dist.'). And then if you look at the resulting distances (the scalar field that should appear on the cloud), you'l...

Sadly, only some intense debugging of the algorithm could help understand the issue... And it's probably a matter of a particular threshold somewhere.

Hum, too bad. Don't hesitate to send me the DXF file (admin@cloudcompare.org) in case there's a minor thing to change on our side. Else, if you can generate the circle (= cylindrical section) coordinates in Excel for instance, you can then export the points as a list of X Y Z coordinates in a .poly ...

Look for the drawMeOnly() method in ccMesh. The draw() method is generic and recursively calls itself on the child entites, calling 'drawMeOnly()' on each entity each time.

Sorry, I can't see the screenshots.

I think you should look at GDAL or PDAL to do the conversion first. CloudCompare only handles orthometric coordinates.

I think it will be safer to rotate the clouds first to that Z becomes the dimensions with the most changes (so more something facing the cliff I guess). The 2.5D Volume Calculation tool only looks for changes along Z.

Well, if the two clouds have roughly the same shape and extents, then yes, your workflow is good. I would just insist on the 'overlap' parameter for the ICP algorithm. This should not be too high otherwise some 'worn' points will be used in the matching process. And it should also take into account ...

Sorry for the late reply.

Sadly, I don't see any tool or trick that would help you...

This is related to the 'Global Shift' mechanism. CC stores only 32bits values to reduce the memory consumption. If you reject the Global Shift at loading time, and keep global coordinates, you'll indeed lose accuracy. You should accept the (temporary) Global shift while working on the cloud. It will...