Unexpected M3C2 Results/Parameter Optimization

[cmackSIO]

Hi everyone, I'm running M3C2 in CC on some coastal cliffs and have some interesting results I was hoping someone would be able to shed some light on.
We have LiDAR point cloud of pre and post rockfall clouds that look like this: (light blue being the pre-event surface, red being the post-event)

hjW9aAr2H002ozLw.png (291.01 KiB) Viewed 2063 times

I run M3C2 in both time directions using the same parameters (D=2, d=1 and L=5),and these are the results:

jaApPc8wmudEpNjM.png (302.84 KiB) Viewed 2063 times

Purple points are identified as part erosion events while green are accretion events. My question is about an odd batch of green points between meters 6 and 7 10.5 meters up the surface, better seen here:

YS0EAWUQnosimOeM.png (267.37 KiB) Viewed 2063 times

These points should be part of the erosion cluster but have been flagged as accretion for some reason and I'm not sure why. I'm assuming the parameters need to be adjusted, it looks like D might be better chosen at 1 or .5 meters to capture the roughness of the cliff in that area, but I was wondering if anyone had any thoughts on this. The whole top section of the light blue cloud is also being omitted from the M3C2 results which is problematic for volume computations later on.

Maybe I would be better off running M3C2 in the same direction but projecting onto cloud 1 first, then onto cloud 2 to get the desired 3D cluster of points with significant change? It seems like the difference in surface normals between the two clouds might be another culprit behind these results.

There is also a small batch of purple erosion points between 10-11 m on the x and 5-6 m on the y that should be accretion instead. Any thoughts on how to optimize the parameters to improve these results would be much appreciated. Cheers!

[daniel]

Sorry, it's a little bit to visualize this way, but I think at least I understood the problem.

I would have questions on how are the normals? Did you compute them before launching M3C2? Were they all good? (no inversion, no null normal?). This is probably the most critical part of this algorithm. Otherwise the algorithm doesn't look for the matching points in the right direction.

Don't hesitate to share some clouds with me also (to admin[at]cloudcompare.org)

[cmackSIO]

Hi Daniel, thanks for your response - I'm not sure how best to display the normal for inspection, I know there is a 'toggle normals' option when I right click on a cloud though this doesn't display them as a vector so it is hard to tell. I also updated the "preferred direction" argument to be -X instead of -Z which improved the output significantly, but I'd love to be able to see the normals to make sure, is there a way you recommend displaying them? I have the Nx Ny Nz values but I'm not sure how to project them onto the cloud or if that is possible within cloud compare? Are you able to get a sense based on the profiles for a better set of parameters to pass? I tried again with D =.5, d=.25 and L=5 which seemed to perform slightly better (although it could have been improved simply because of the -X argument). I'll send along the clouds and parameter file via email, thanks for being willing to take a look at it, let me know if you see any obvious tweaks that should be made in parameter choices.
Cheers!

[daniel]

Well, the normals are indeed always a little bit hard to compute.

Regarding their visualization, you can deactivate all colors or scalar fields, and turn the normals. Then, if points appear black, it means that their normal is pointing in the same direction as what you are currently looking (i.e. you are looking at the point normal "from the back"). Else it will be a shade of gray to white, depending on how much you are facing it.

Another way to display normals is by using the 'Edit > Normals > Convert to HSV' option. It's just not that simple to interpret the colors either ;)

If you have some Nx, Ny, Nz values (from an ASCII or PLY file?) then you can assign them to the Nx, Ny and Nz fields of a cloud at loading time (that's the ideal scenario). Else you'll have to compute them with the 'Edit > Normals > Compute' tool. Unless your cloud is flat, I would recommend using a little bit more evolved option (such as the '+/-barycenter' options, which means that the normals all point toward the entity barycenter, or the opposite).

I'll try to look at your files ASAP.

[daniel]

So what I did:
- compute the Normals with 'Edit > Normals > Compute' with a radius of 1m and '+Z' as default orientation
- I saw that there were some black parts here and there du to overhangs. Then I used 'Edit > Normals > Orient > Minimum spanning tree' (default parameter for the number of neighbors) and it fixed the issue in most cases. You can do this in one shot (just select 'Minimum spanning tree' to orient normals directly in the first 'Compute Normals' dialog).
- do that for the 2 clouds (or at least the cloud you want to use as 'first' cloud in M3C2). Note that I got a cleaner result with the September cloud
- then you can use M3C2
- I personally used a scale of 0.5m (as you did) and a max depth of 10m. No subsampling (the clouds are not that big), and make sure the 'Cloud #1 normals' are used

Here is the result:

m3c2_result.jpg (50.08 KiB) Viewed 1845 times

Since the average distance is 0.18m, I wonder if the registration between the 2 clouds is very good? Maybe it would make sens to refine it first (with ICP for instance).