CloudCompare forum

I'm looking at comparing a scan cloud (that has good normals) with a mesh (also with correct per-triangle normals), but the scan cloud is of a thin part that is distorted enough that the nearest triangle for some regions is the opposite side of the thin surface, where the cloud normal and triangle normal are near 180° from one another. The result is that the signed distance goes negative, then to zero as it passes through the opposite wall, then more positive as you move into the distorted region, when the actual signed distance should just continue going more negative. The 'inside' wall correctly shows the signed distance increasing positive continuously.

From going through the documentation, it seems currently cloud to mesh signed distance just grabs the nearest triangle and computes a signed distance using the triangle's normal, but is there a way to ignore triangles with a normal different than the point normal by some threshold? I.e. if the nearest triangle's normal differs from the point normal by more than (for example) 100°, ignore it and keep looking for the next nearest triangle until you hit max distance or find a triangle within the orientation limit?

I started digging into the source, and it looks like it's not an option in CCCoreLib, but the change seems straightforward. I'm not a real programmer and can't make it into a PR, but I can describe the desired change a bit. The change I propose would be another UI field, rather than a hardcoded value, that then passes the max angle parameter (if the user wants to use it) along until it reaches ComparePointsAndTriangles, and then that function can discard the triangle as a candidate if the dot product (prior to taking the absolute value) gives an angle outside the range specified. Then I think the rest of the calculations should continue and the signed distance results should fall out more as expected.

Hum, I fear another issue is that currently CCCoreLib doesn't know/care about the point normals. This information is not passed to CCCoreLib.

Anyway, anyone could perform this change, as long as it's done properly ;)

Is the cloud point normal information discarded because CCCoreLib doesn't have it in its cloud datatype? I'm just trying to wrangle some 3D scan data and would love to help but am probably going to have more questions than useful file changes for a bit, particularly since I don't really have a handle on building a dev environment to pull the code down and play with debugging.

Some pointers on setting up a dev environment and figuring where I could hack in the extra functionality in a branch would be helpful, then I could try to contribute at least a hacked together example, and you could pull it in in a neater fashion as a separate function and work it into the UI?

Yes, CCCoreLib doesn't manage normals at all. So it would definitely not be easy to pass this information and use it in the existing algorithm without a lot of refactoring...