CloudCompare forum

I'm working with some pointcloud of very rocky,craggy spaces where there's lots of occlusion and low overlap.

markers aren't ideal, and feature based manual alignment is going so far.

off the cuff ICP is way out no matter what setting I try
and while manual segmenting as per the manual does some good, the spread of things is so varied I've tried the following:

use cloud to cloud comparison to highlight points within a given range
faff with the SF to give a hi weight to those with a small distance and use this in the ICP.

in my head, the ICP algortihm should be doing something similar anyway, looking first for the closest points?
But it 'appears' to be helping.

Is this a sensible approach or am i just wasting my time?

Hard to tell (can I see a snapshot of the data maybe? Or even the files?).

The default ICP algorithm is really trying to associate all points of the aligned cloud with points in the reference cloud. The points that don't have actual equivalents in the reference cloud will still be associated (to the 'nearest' points in the reference cloud, but they may be far actually). In a way ICP tries to minimize the overall distances. So points without a match tend to shift the registration (towards themselves).

This is why you approach might help. But this is also why it's important to set the 'overlap' parameter correctly (so that CC can ignore the points that are originally far and change the subset of points at each iteration). Another older options was the 'remove farthest points...' one, but it can lead to strange results in some cases.

Thanks Daniel,

I am attempting to estimate the overlap, it was actually trying to give myself more of a visual clue as to a good estimate which started me down this route. Though I don't quite have the knack of efficient cloud to cloud distance comparison, some clouds (open area especially) seem to jam up and take forever to process

I'll keep poking around and try and get some meaningful pics along the way.

Thanks again.

Hi again,

This is what I've been trying and the logic behind it.
I guess it is the idea behind remove far points? But gives some manual control and a bit of eye-on checks.

First pic - an example of the very patchy cloud (a surface one here)
Second pic - segments of 2 meshes at an area with high density of the model (I've picked quite a small area in this instance)

grey is model cloud.

red are points in the data cloud that aren't in the model cloud.

green to blue are ones in my 'kept' range of something like 10mm, decided with a bit of judicious eyeballing.

I use this green-blue set to fine register with the model, then apply the transform to the entire cloud.
The idea is that any nearest neighbouring only takes places with neighbours that are likely to exist. Though of course if the original alignment is off a lot it could backfire.

Do you think this would work, or by reducing myself to small areas am I shooting myself in the foot?

and I realise there are probably better ways for capturing the data in terms of the coverage, but that's another battle.

sorry for the partial images, very unstable internet at the moment, hopefully get them to upload eventually.

After some more poking around, I don't think it is providing any significant advantage over the workflow with segments suggested in the manual.
As you said the overlap estimation is key.

Thanks for humouring me though.

All the best.

With the full pictures it's better. Indeed, with such data I would start with a very small overlap (it can even be 10% or 20%) and then maybe do it a second time with a slightly higher percentage (but computing the distances before is also a good help to find the right overlap percentage).

Thanks again.

I'm struggling with similar task, and I'm wondering if it would be beneficial to use some scalar fields as weights (planarity, density, PCA2, etc) in this case?
Or in general, does it make sense to use any of the available geometric features SFs as weights for registration?

Interesting suggestion.

I have never been super happy with the improvement of using a scalar field as weights, but maybe it would be worth to study...