1

After reading the two nice posts Algorithm for simplifying 3d surface? https://stackoverflow.com/questions/838761/robust-algorithm-for-surface-reconstruction-from-3d-point-cloud I have still a question about surface reconstruction.

I have some 3d point cloud data from range camera. It means that the point cloud data is noisy, has only coordination (x,y,z) information and represents only a partial surface of a scanned scene (aka. 2.5D data).

Before trying to mesh-lize them, I run some alignment algorithm (e.g. ICP) to merge multiple range data into one. Somehow the alignment is not perfect, it let the merge data sets have some not well overlapping surface artifacts and the whole data gets even more noisy!

here is an illustration.

here are points representing a surface (shown as a line)
.....................................................  


here are points representing actually the same surface as the one above,
but due to imperfect alignment of multiple data sets they seem overlapping like onion shell.
............................
  .............................
                   ...............................
              .......................................

can the algorithms (e.g. ball pivoting, poisson, marching cubes) handle such situation? or do I need some preprocessing to make the data set thinner to reduce the overlapping surfaces?

btw, I have tried MeshLab with just ball pivoting to reconstruct surface from such data sets. It works but some of surface normals are generated in wrong direction. I think that the overlapping points cause such problem.

The surface generated in MeshLab, the surface in white and black having different direction of normals. image

Thanks for any suggestion and possible answer.

Community
  • 1
  • 1
rnd_nr_gen
  • 2,203
  • 3
  • 36
  • 55

1 Answers1

4

I hope you're still interested in an answer. One thing you can try is to define your ICP using point-to-plane distance instead of point-to-point distance. Point to point distance looks like this, where a and b are in the target point set and p is a point from the set you are registering with ICP. The closest point is a and the distance is |a-p|.

a--------b
 \
  \
   p

Point-to-plane distance is like this, with c being the projection of p onto line ab and the distance being |c-p|.

a--c-----b
   |
   |
   p

The reason point-to-plane can be advantageous is in situations like this, where '.' points are from one scan and 'o' points are from another. ICP can get stuck in a local minimum like this where the .'s and o's in the horizontal line are matched perfectly but the ones in the vertical line aren't. It can't "move" the 'o's to the left because doing so will increase the misalignment of the horizontal points too much. 

.   .o   .o   .o   .o   .o   .o   .o
.  o
.  o
.  o

With a point-to-plane distance, you would incur no error from the horizontal points as you slide the 'o's to the left, so you wouldn't get stuck in that local minimum. I have seen the "onion" like error you described as a result of using point-to-point distance with ICP.

Another thing you can try is clustering your points, if you can live with the reduction in resolution. Meshlab has a filter that will do this: "Filters->Sampling->Clustered vertex Subsampling". That might be able to reduce the "onion-like layering".

Regarding the inconsistent normals that you are getting out of meshlab, if all you care about is visualizing them in meshlab, ctrl-d will turn on "double side lighting" and eliminate the black areas. If you really do need consistent normals, meshlab has an enticingly-named filter called "Normals, Curvatures and Orientation->Reorient all faces coherently", which unfortunately doesn't work for me. Depending on the kind of data you have, and especially if it is coming from a range sensor, then you already know that the normal of the mesh face should point toward your sensor, so it would be easy to post-process your data and flip the ones pointing the wrong way (look at sign of dot-product of the normal and the viewing/measuring direction).

cape1232
  • 999
  • 6
  • 21