CloudCompare forum

He guys
I'm new here and doing my first tasks with Cloud Compare now. I have encountered a weird functionality in Cloud Compare. First about the tasks I’m trying to fulfil. I have two point clouds and want to compare them (perfect task for Cloud Compare, I guess). The expected movements of the object are along the y axis and the cloud itself just expands x & z axis.
So, I want that the normals are computed along the positive Y axis. I used the function Edit/ Normals/ Compute, and set the preferred direction along +Y. After that I calculated a mesh (without updating normals) and then used the Cloud2Mesh-Distance calculation. My expectation would be as followed (corrected me, If I’m wrong):
If the compared point is on the side of the positive normal (should be +Y) it should get a positive sign and if it is on the negative side of the normal (should be -Y) it should get a negative sign.

I come to the following error: It doesn’t matter if I choose +Y or -Y, when I calculated the normals. I always get the exact same results. I also tried it with a test example (Just three points building a triangle and 1 single point) and come to the same results, that it ignored the preferred direction for the normals calculation (also if I build the example along a different axis).
Then I came across a second error, while I did my testing. If I varied the coordinated (made all negative, made only x negative, x &z negative and y positive, …) I turned out, although I always used the same parameter settings, I got different results. Sometimes the sign was positive, if the test-point was in front of the triangle and sometimes negative. I couldn’t figure out after a schema. Seemed to me nearly arbitrary.
Maybe someone can help me and can clarify the calculation idea of Cloud Compare in this scenario for me and show me the best practice way, to be sure on which side of my point cloud the second one moved.

Thanks in advance

Well, those are not errors actually, but more 'limitations' of the methods you have used ;)

1) The cloud / cloud distance doesn't rely on the normal. It's the nearest point distance (it's not searched in a particular distance, it's just the nearest point) and we can't even use the point normal to sign the distance because it just doesn't work sometimes (this is why the result is always positive in this case).

2) The cloud / mesh distance does the same kind of computation except that it finds the nearest 'triangle' (and in some cases, especially for sharp edges, the point doesn't project on any triangle (in an orthogonal way), so we have to take the projection on the edges and it can produce some artifacts. Anyway, in this case we can use the triangle normal to sign the distance (because we know more clearly what is the inside and the outside of the mesh surface. You get signed distances in this case.

3) The 'preferred orientation' in the normals computation dialog ('+Y' or '-Y') is only used to orient the normal (not to make it parallel to +Y or -Y (but I guess you have already figured that)

4) Last but not least, to do what you are trying to do, you'd better use the 'M3C2' algorithm. It's a little bit more complicated (you have to read the documentation here: http://www.cloudcompare.org/doc/wiki/in ... 2_(plugin) - and maybe even the article). With this plugin you can use normals to search for the nearest 'neighbor' along a given direction. You can even force purely vertical or horizontal normals, etc.

Hello Daniel
Big thanks for your answer.

According 3.)
I understand that I can't force the normals to be along y-axis, this would be necessary for me. But I still don’t get the point, why I get the same results, if I use +Y or -Y. I would except that the normal would point in the opposite direction, but this doesn’t seem to be.

4. ) I already heard about the M3C2-plugin, but I’m still confused about the parameters for it. Does it computed distance along “cloud-1 normals” to “Cloud-2” (sclar-field = quantity of how much cloud 2 moved in respected to “fixed” cloud 1) or the other way? How I can activate the other outputs like the “distance uncertainty”. I always get just one output with the singed distances?

Thanks for your help

3) Only the normals 'direction' will change (they will be facing one way or another). The 'preferred dimension' is only used to sign the normal.

(Of course, if most of the normals are pointing along Z or X, it might not be very effective to sign them based on their Y coordinate). Visually you should see that the points you are facing from backward will be black. You can also manually 'invert' the normals globally with 'Edit > Normals > Invert' (it will have the same effect as switching between +Y and -Y).

And last but not least, as the normal is not used for C2C or C2M (with per-vertex normals) there won't be any difference.

4) Yes you can use (or compute) normals for cloud 1, and they are used to find the equivalent points in the second cloud. And you can switch cloud 1 and 2 in case it's necessary.

To change the outputs, you have to select the active 'scalar field' in the cloud properties. In CC, clouds can have multiple scalar fields.

Ok, let me try if I understood you correct:
3.) So, in the Cloud2Mesh algorithm the normals are, which I calculated previously are not considered (despite for the calculation of the mesh)?
4.) With the pictures attached. Does the M3C2 no calculated the distance from Cloud 1 along its normals to Cloud 2? Which would mean the distance represents the movement from Cloud 2 relatively to Cloud 2.

(I must write the parameters manually, because I can’t attach images. It Says the quota for this website has been reached)
Cloud-1 (not checked): Name-001 (is my not so dense reference)
Cloud-2 (checked): Name-002 (is the moved point-cloud, I want the result to be as dense as this point cloud)
Main parameter:
Normals: use cloud-1 is checked
Projection: 0.31; max depth: 16.39
Core-Points:
use other cloud: Name-002

Normals:
Preferred Orientation: -Y

Output:
Project core point on: “Keep original positions”; use original cloud is checked

3) Yes, only per-triangle normals can be used (not per-vertex). And if there's no such normals, we compute them with the triangle vertices (direct order).

4) I'll have to fix this quota issue. Because it's too hard to understand ;)

However if you only have normals on the first cloud, then yes you are bound to use it as cloud 1 and then project the distances on Cloud 2.

3) Yes, only per-triangle normals can be used (not per-vertex). And if there's no such normals, we compute them with the triangle vertices (direct order).

4) I'll have to fix this quota issue. Because it's too hard to understand ;)

However if you only have normals on the first cloud, then yes you are bound to use it as cloud 1 and then project the distances on Cloud 2.

Edit: I fixed the quota issue.