Cloud to mesh - am I expecting too much from mesh?

[senmay]

Hello,

I have a point cloud containing grating floors with railings, and I'm trying to create a nice-looking mesh, but after a few hours of playing around with the options, I can't get a satisfactory result. I'm quite new to CloudCompare, and I was wondering if I'm missing something. Could it be related to improperly computed normals (local surface = triangulation, orientation using minimum spanning tree with knn=8)? I've tried different settings, but none are satisfying. After reaching octree depth 11, the difference is barely noticeable. Is it possible to achieve better results in this case? I was thinking about segmenting different objects and working from there, but I'd prefer to avoid that if possible.

Attachments:

1. Point cloud
2. Point cloud with normals
3. Mesh - Normals (local surface = triangulation, orientation using minimum spanning tree with knn=8), filtered scalar mesh from PoissonRecon, octree depth = 12 with default advanced options.
Cheers.

[daniel]

Yes, it's all about the normals. Computing properly oriented normals on railings or other small features can be really challenging. You would need a lot of points on 'both' sides. You could maybe achieve that by segmenting the cloud in various bits to be able to force the right normal orientation for each of them, but that can be very tedious.

The best way generally is either to import these normals, or if you have a structured file format with 'scan grids' (such as Faro or some E57 files), then CC will be able to resolve the normal orientation robustly.

[jedfrechette]

For an object like that I’d say your mesh actually looks pretty good.

Something like that is going to be difficult to get a clean mesh from. In addition to good normals you’ll also need an extremely dense point cloud that captures the entire surface with no gaps, which is hard to get with structures like the railing that introduce lots of occlusions. The mesh floor grating is going to be even worse and a tripod lidar scanner won’t capture enough detail on the individual grids to be able to mesh them as anything other than a rough surface.

[senmay]

Thank you for your answers!

I'm still unsure about how normals are imported from scanner exports. I used a Trimble X7 scanner and exported the data as .tdx and .rcp files. Can these exports already include pre-calculated normals? Unfortunately, I don’t have access to Trimble’s native software (RealWorks) to work with these files, so I’m wondering if there is a way to solve the issue with normals. I tried exporting the point cloud from Trimble Business Center as a structured .e57, but after importing it into CloudCompare, the normals and mesh quality appear to be significantly worse.

[daniel]

I see that you have the scanner positions. Do you also have individual scans? (i.e. multiple clouds?). In which case you can also use the sensor position to properly orient the normals.

If you have a doubt, you can still send me the file (to admin@cloudcompare.org) so that I can check on my side.

[daniel]

Ok, so I got the data and while it's very good on paper (individual E57 scans with sensor position and scan grids), they are filled with (0, 0, 0) points that completely mess things. They all have around 50 million (0, 0, 0) points out of 60 million. They probably corresponds to all the directions in which the laser didn't return. But sadly these points are not even flagged as 'invalid' in the E57 file (as they should be)...

So first, you have to remove these points (with 'Tools > Other > Remove duplicate points' - keep the default parameter).

Sadly this will just create a lot of holes in the scan grid, which makes it useless. That's a shame because it's super efficient to compute normals with these... But you can still use the sensor position. This is mostly longer in terms of computation time.

You can use the following parameters (on each cleaned individual scan). The important thing is to not use the scan grid:

compute_normals_example.jpg (41.45 KiB) Viewed 2353 times

Of course if you have a lot of memory you can load all the clouds at once and call all these tools on the 8 scans at once.

It should give you quite clean normals:

better_normals.JPG (385.84 KiB) Viewed 2353 times

Eventually, you can merge the cleaned clouds with normals and compute the mesh with PoissonRecon.

However, you'll need a very high depth/octree level to reach this level of accuracy. And play with the resulting mesh 'density'. Still, I see that not all the bars are reconstructed properly (probably because there's not enough point on one side):

mesh_closeup.JPG (210.13 KiB) Viewed 2353 times

(I only reconstructed a small portion of the cloud here)

[senmay]

Ok, quality of the mesh is indeed better thanks to the methods you suggested. Regarding to those bad points I don't get how those points can have intensity and not XYZ. It means that laser had to return to source or my understanding is wrong?

X Y Z R G B Intensity
0.00000 0.00000 0.00000 34 37 46 0.250984

Thanks for help!

[daniel]

Well, that would be a question for the scanner manufacturer ;)

Maybe it's a confidence issue (but I agree it's weird that they keep half of the information).