Page 2 of 3
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 18, 2017 12:59 pm
by ccadiou01
Hello Daniel
I think this topic is the good one for my question.
I wanted to apply the PoissonRecon tool on a pointcloud representing a dam. Therefor I computed the normals with these parameters:
- quadric model (good for curvy surfaces like the dam)
- Radius = 0.051 instead of 0.041 (0.041 was the auto-computed radius) I understood a bigger radius was good to get better normals
- minimum spanning tree with knn = 6
Computation took a lot of time because of my computer but the normals were good (white and not black).
Then I used the PoissonRecon tool with octree depth = 11 and with the output density as SF (SF = scalar fields, right?)
- Reconstruction_poisson_1.png (235.79 KiB) Viewed 7230 times
- Reconstruction_poisson_2.png (227.83 KiB) Viewed 7230 times
- Reconstruction_poisson_3.png (209.82 KiB) Viewed 7230 times
The 3 attached pictures show the result. The front side of the dam is really nice I guess (red/orange part) except for the left side but I know it's because of the noise. And the back side of the dam is really strange. I only scanned the front side.
Could you explain me why the reconstruction is really weird?
(I think you are french, so am I. You can answer in french if you want)
Best regards,
Cyril.
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 18, 2017 1:06 pm
by daniel
Poisson always create a closed mesh by default. You then have to reduce its coverage.
See the documentation about PoissonRecon:
http://www.cloudcompare.org/doc/wiki/in ... n_(plugin) (especially the section about
Using the output density).
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 18, 2017 2:00 pm
by ccadiou01
Thank you for the answer. I didn't read the whole documentation --'
I get a better result now.
- Reconstruction_poisson_5.png (199.55 KiB) Viewed 7226 times
daniel wrote:It's due to the noise that 'connects' the surfaces in weird ways and the orientation propagation fails...
Apart from playing with the 'number of neighbors' parameter of the normals orientation algorithm, you'll have to segment the cloud in multiple parts and compute the normals on each part and eventually merge those parts back together.
Like I said, the left part of the reconstruction is not very good because of the noise. Should I increase maximum number of neighbors (knn) just on this part of the pointcloud in order to solve the problem? If yes, how could I guess how many neighbors I have to choose? Initial value is 6.
I have an other question. The purpose of the reconstruction is dam monitoring. I scanned the dam in summer and in winter and I now want to compare the two poinclouds in order to mesure the distance between them. Do you think it's better to compare to meshes or a mesh and a pointcloud?
Thanks in advance,
Cyril.
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 18, 2017 8:05 pm
by daniel
If there's noise, then you'll see it whatever the normals are (especially if you mesh with a high octree level). You'll have to remove the noise first (with SOR maybe?).
And comparing a point cloud with a mesh (as reference) is sufficient. It's even the only choice you have with CC ;)
Re: CloudCompare mesh adds unwanted surface
Posted: Thu Jan 19, 2017 7:06 am
by ccadiou01
Yes I already used SOR but it removed to much points. I'll try it again with other parameters.
It's also possible to compare two meshes: "If you have selected two meshes, CloudCompare will ask you to define the roles of each mesh"
But I'll use cloud-to-mesh distance ;)
Thanks
Re: CloudCompare mesh adds unwanted surface
Posted: Thu Jan 19, 2017 5:41 pm
by daniel
Yes, you can decrease the 'sigma' parameter so that SOR removes less points.
And even if you can technically select two meshes, CC will in fact only use the vertices of the compared mesh. Therefore it's more like a cloud/mesh distance (but the distances are then linearly interpolated on the compared mesh triangles - which can be good... or not ;).
Re: CloudCompare mesh adds unwanted surface
Posted: Fri Jan 20, 2017 7:39 am
by ccadiou01
Tank you for the answer.
An other question, does octree depth mean octree level?
You saw my pictures, I'm computing a mesh of the dam with PoissonRecon and I tried it with diferrent octree depth
- octree depth = 8 ==> bad result
- octree depth = 11 ==> nice result
- octree depth = 14 ==> my computer crashed
How can I guess which octree depth I have to choose?
Re: CloudCompare mesh adds unwanted surface
Posted: Fri Jan 20, 2017 8:06 am
by daniel
Indeed, for PoissonRecon (the Poisson Surface Reconstruction library from M. Kazhdan), the octree depth is the maximum octree level, as its octree is adaptative and doesn't necessarily reach this depth if there are not enough points locally.
You have to imagine that the cloud is projected into a grid with 2^depth cells along each dimension (the grid being a cube enclosing your cloud). Level 14 is huge (2^14 = 16 384 cells per dimension = up to 4 398 046 511 104 cells - luckily most of them are empty ;). The best depth / resolution depends on the size of your cloud. If a dam is 100 meters wide, at level 10, the cells will be ~0.1 m = 10 cm wide (2^10 = 1024). But of course it also depends on your cloud density (you need at least some points in each cell to fill them).
The deeper the octree is, the finer the reconstruction will be. But you generally don't need to go above 12 or 13 if you have a huge cloud (in which case you'd better split it if possible by the way). And in this case you'd better have a lot of memory ;)
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 25, 2017 10:10 am
by ccadiou01
Hello Daniel, thank you for the reply.
It's easier to understand now.
Could I send you 2 pointclouds per e-mail in order to do some tests? I computed distances between them by using C2C, C2M and M3C2 and I think I reached the best result but maybe you'll be luckier.
If you agree, may I have your adress please?
Re: CloudCompare mesh adds unwanted surface
Posted: Wed Jan 25, 2017 8:34 pm
by daniel
Yep, don't hesitate: cloudcompare [at] danielgm.net