Command Line Normals Generation

[william_pinnaclevl]

I am currently working with multiple point clouds and am experiencing a few issues when running the Octree normals generation via the command line.

I am using CloudCompare 2.10.x on Ubuntu 16.04 and trying the following command

CloudCompare -SILENT -C_EXPORT_FMT ASC -SEP COMMA -EXT CSV -O test.e57 -OCTREE_NORMALS 0.003 -SAVE_CLOUDS FILE test.xyz

I have tried the above command on some scans and it works very well however when I try the same on a more curved scan I find that some of the normals have been inverted.

OrientationError.png (69.15 KiB) Viewed 4109 times

The above screenshot shows the results of running the command on the point cloud. I'm aware there is an invert normals function but as only some of the normals are incorrect this does not help me. Could anyone shed any light as to why the algorithm does this and what I can do to align all the normals in the correct direction?

Thanks

[daniel]

By default, as specified in the documentation, normals are not oriented after a call to 'OCTREE_NORMALS'.

Therefore some normals may not be in the same direction as the others. You have to call another method to orient the normals. And for now there's only one available via the command line (-ORIENT_NORMS_MST): https://www.cloudcompare.org/doc/wiki/i ... _line_mode

[william_pinnaclevl]

Hi Daniel,

Thank you for the response. I should have included a bit more information with my original post as I was already aligning my data using the MST command line. I took a few exports from the command line before and after applying the MST and found that for curved scans the MST algorithm seemed to change the straightline of inverted normals into a strange almost circular shape of inverted normals

ExampleOutput.png (66.36 KiB) Viewed 4096 times

I've done my best to visualise it for you but as far as I can tell I thought aligning it via MST should result in all the normals following the same general direction. The most confusing thing is when you run this in the CloudCompare GUI I can not produce the same result, it is always correct but in the command line it does this sometimes. I've reviewed the C++ flow from both the front end and the command line and they both seem to convert to the same code with the same output. Do you have any ideas why the MST algorithm would produce such strange results?

[william_pinnaclevl]

Further to my previous post I thought I'd add a few more examples of the issue I am facing. I've attached two screenshots both that computed and orientated the normals for an E57 file, one on the command line and the other within the application. Both using version 2.10.x, the command line on Ubuntu 16.04 and application on Windows 10

Normals computed and orientated within the application

Onscreen.PNG (27.66 KiB) Viewed 3923 times

Normals computed and orientated from the command line

CommandLine.PNG (434.96 KiB) Viewed 3923 times

Both use the same e57 file with the same settings. I am running the following command on the command line

CloudCompare -SILENT -C_EXPORT_FMT ASC -SEP COMMA -EXT CSV -AUTO_SAVE OFF -O test.e57 -OCTREE_NORMALS 0.003 -ORIENT_NORMS_MST 6 -SAVE_CLOUDS FILE test.xyz

Within the application I am running Edit -> Normals -> Compute and entering Quadric, 0.003 Radius, MST with knn=6

Does anyone know why I am getting such a different result? I might add if I take the file with the incorrect normals and then orientate it within the application it then looks like the onscreen version, if I run it again on the command line it goes back to the command line version.