Same cell width, different output

[cdcseacave]

I am trying to make PoissonRecon to create consistent meshes if the scene varies in size and I am not able to no matter I try. Sorry if there is something obvious I'm missing, but I thought using same Width will do it.

So here is a little experiment: I have a point cloud from which I select only the center; reconstructing the full point cloud and the cut point cloud with the same params (including width), produce totally different meshes for the common scene section. See bellow:

full vs cut overall view:

close-up full vs cut common section:

I print out some details from GetBoundingBoxXForm and here is how they compare:
full: Estimated: scene scale 5440.12, octree depth 15, cell width 0.166019
cut: Estimated: scene scale 340.01, octree depth 11, cell width 0.166019

Is the problem that the floating point reaches the end of precision as the scene is scaled in the interval [-0.5..0.5] and so the reconstruction suffers from rounding errors? Is this scaling necessary or we can use the full floating point range?

How can I reconstruct the full point cloud and obtain the same mesh quality as in the cut version?

[mkazhdan]

In the zoomed in picture of the tractor, which is the result of the cut version and which is from the entire dataset?

[cdcseacave]

the smooth looking one is the cut version

[mkazhdan]

Can you share the dataset?

…

On May 20, 2019 4:34:35 AM EDT, cDc ***@***.***> wrote: the smooth looking one is the cut version -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #110 (comment)

[cdcseacave]

Here is the dataset: https://send.firefox.com/download/e783829fc367e550/#Kdv_gLEEsEwlbQRDYeC3pA
and this is the bounding box I used for cutting:

box.zip

I processed it using floats not doubles.

[mkazhdan]

Thanks.
Can you send me the parameters you used for running the reconstruction?

[mkazhdan]

Unfortunately, it appears that the link has expired.

[cdcseacave]

Sry, pls try this link: https://send.firefox.com/download/c690f65082726908/#4SuMqSHC3n4XSTpitpWbLA
I used all default params, except setting --width 0.166019 and --InCore as I have a lot of RAM.

[mkazhdan]

I'm a bit confused by the box.zip file. It looks like all the points are withing the the box [-1,1]^3, but the ply file you provided has a much larger extent.

[cdcseacave]

These are the 8 vertices contained in the box.ply I sent to you, which are the corners of the box I used to cut out the background and keep only the middle scene with the caterpillar (copy&paste from the file above, as the ply is just a text file):

-59.3492 14.4696 -36.0144 
53.2463 -67.338 -36.0144 
-16.1518 73.9241 -36.0144 
96.4437 -7.88358 -36.0144 
-59.3492 14.4696 37.4761 
53.2463 -67.338 37.4761 
-16.1518 73.9241 37.4761 
96.4437 -7.88358 37.4761 

However none of these are important, this issue can be seen on any pointcloud and any cut selection. The only thing you need to reproduce this is to have a scene with a huge bounding-box compared to the resolution of the object of interest (or in general, compared to the resolution of the scene). In other words when:

cell_width << scene_width

[cdcseacave]

hi @mkazhdan; did u have a chance to think about this issue? do u have any tips on how to solve this?

[mkazhdan]

I think I have identified the problem, though I still need to come up with a nice fix.
For now, you should be able to get consistent results by disabling the screening, i.e. adding the "--pointWeight 0" flag.
This is suboptimal because you don't interpolate the data as well, but it's a quick fix for now.

[cdcseacave]

I confirm that unscreened version does not suffer of this issue, however the thin structures (like pipes or thin surface) are not recovered anymore (pls compare the bellow with the reconstruction posted earlier):

[mkazhdan]

That's what I was seeing as well. I think the quick and easy fix is to use a smaller "--pointWeight" value. Maybe something like 1/8.

[cdcseacave]

thx for the tip, I did try, and some of the thin structure is recovered, but the "quantization" like looking has returned too:

[mkazhdan]

It may make sense to use a still smaller value.