Closed/open holes in mesh

[adrian121]

Hello!

I’ve ran the CloudCompare (downloaded on 14th September). I did the Poisson reconstruction of the point cloud. It can be downloaded here: https://1drv.ms/f/s!AopT_07zbG6ji0tvVuuPTrjDnHdj

Then I did the same using program downloaded from the website "CloudCompare 2.8 beta
installer version (last updated on the 9/29/2016)".

I get different outputs from these runs.

One point cloud is reconstructed with closed holes (downloaded on 14th September) and the same point cloud after reconstruction has holes (updated on the 9/29/2016). Is there any parameter defining that behavior?

I used the same parameters for both runs:
output density as SF: false,
octre depth: 8,
sample per node: 1.5,
full depth: 5,
point weight: 4.00,
boundry: Neumann (in newer version).

[daniel]

Indeed, we upgraded PoissonRecon (the library developped by Misha Kazhdan) with the latest version (V9.0). Previously we were using version 8.0.
http://www.cs.jhu.edu/~misha/Code/Poiss ... ersion9.0/

Apparently this new version changes many things. For instance, the user now has more options for the limit conditions (Neumann, Dirichlet and free - however, none of the new options seem to fix your issue). On another hand, looking at your cloud I don't see why / how the previous version was closing the big hole below the statute (as there are no points in this area, and the normals are not particularly directed towards the hole center).

Maybe you should ask Misha directly?

[adrian121]

Professor Misha helped me to resolve this issue. In V9.0 if mesh should have closed holes, the flag "--bType 2" should be added to arguments string. Professor said: "This runs the reconstruction using Dirichlet boundary conditions, so that the faces of the bounding-box are forced to be outside of the shape, and any holes are necessarily closed off in the interior"

[daniel]

Well, you have the option to set Dirichlet boundaries... but the result is not what I would have expected.

Therefore I tinkered a little and realized that the normals should now be inverted to get the same result as before?! At least it seems to work this way... I've updated the online beta version.