Hello Daniel & Dimitri
I am french but I post that request in case it could be useful in the futur for the overall Cloud compare community.
we are assessing different SFM soft vs Laser Scanner instrument in order to qualify pro/cons of photogrammetry for Heritage 3D survey.
Here I am comparing Pointcloud generated with AGISOFT METASHAPE (formely Photoscan) vs FARO static laser scanner pointcloud.
instead of using C2C I was testing a cloud 2 cloud comparison with M3C2 plugin.
thanks to the wiki tuto https://www.cloudcompare.org/doc/wiki/i ... 2_(plugin) I have been able to set up correctly core pts and registration error (basically the GCP residual when georef photo project in MEtashape. Please note GCP were picked pts from the Faro Pointcloud).
the result is showing interesting phenomenon, we can notice local bump in the Dense Correlated Point Cloud but still very close to the FARO pointcloud (around 3mm).
M3C2 looks promising for that study.
However I don't catch why M3C2 hasn't kept the initial Normal of Metashape Pointcloud ? on the resulting Normals are oriented well on the left part but wrongly on the right Part...
I miss something here with the normal. all nomal should be orientated inner the dome... but on that M3C2 result most of them are bladly orientated...
How can I defined or specify in M3C2 option I want to preserve the normal of my core pts which is here METASHAPE pointcloud that I used ?
thanks
always a pleasure to use CloudCompare
antoine
[M3C2] and normals
Re: [M3C2] and normals
I"ve got it.
the source FARO TLS pointcloud wasn't imported as a structure grid cloud... Instead I've got an unstructured E57 pointcloud.
so I had to recompute the normal of that ingredient so that I could asks M3C2 to works with those updated normals (In main Parameters tabs = choose use cloud #1 normals)
and therefore the result M3C2 pointcloud looks more consistent with normal
however there is still a slight issue with that square patterns... Does anyone know where comes it from ?
antoine
the source FARO TLS pointcloud wasn't imported as a structure grid cloud... Instead I've got an unstructured E57 pointcloud.
so I had to recompute the normal of that ingredient so that I could asks M3C2 to works with those updated normals (In main Parameters tabs = choose use cloud #1 normals)
and therefore the result M3C2 pointcloud looks more consistent with normal
however there is still a slight issue with that square patterns... Does anyone know where comes it from ?
antoine
Re: [M3C2] and normals
Nice!
Where this 'tiling' effect on the dome comes from?
Where this 'tiling' effect on the dome comes from?
Daniel, CloudCompare admin
Re: [M3C2] and normals
Hi Daniel
that tilling effect also stroke me...
I don't catch if it's rather the voxel effect from Cloud Compare or a tiling effect of the Dense Point Computation from METASHAPE...
that tilling effect also stroke me...
I don't catch if it's rather the voxel effect from Cloud Compare or a tiling effect of the Dense Point Computation from METASHAPE...
Re: [M3C2] and normals
I would be surprised that it comes from CloudCompare.... especially since M3C2 is not using the octree this way (it uses cylinders).
Daniel, CloudCompare admin
-
- Posts: 187
- Joined: Tue Mar 05, 2019 3:59 pm
Re: [M3C2] and normals
I have experienced the square tiling patterns on curved surfaces in the past when comparing various scanners, in my case I was able to determine that one sensors resolution combined with multiple passes/positions would cause local flat spots which were difficult to visualize on a single cloud/sensor by itself, only by comparing it to something that was either more representative of the curve or by comparing against a sphere with the cloud to primitive distance measurement tool would they local square regions become apparent.
By the way this isn't to say it is not a CloudCompare artifact, only wanting to point out there maybe another real world physical reason for apparent tiling
By the way this isn't to say it is not a CloudCompare artifact, only wanting to point out there maybe another real world physical reason for apparent tiling