Good mornig to everybody,
I know that CloudCompare is more oriented in working with point clouds, but I'm interested in comparing two surfaces, one obtained with MeshLab and the other obtained by CloudCompare.
I've tried the Poisson algorithm, both on CC and ML, and I'm wondering what is the correspondance between the parameters of the two methods.
It's clear concerning the "octree depth" and the "samples per node", but what about "minimum depth" and "point weight"?
Further information: I'm using the CC 2.6 version on Windows 7.
Thank you very much!
Poisson parameters correspondence between MeshLab and CC
Re: Poisson parameters correspondence between MeshLab and CC
Hi,
In CC we are using the latest version of the PoissonRecon library (by M. Kahzdan - see http://www.cs.jhu.edu/~misha/Code/Poiss ... rsion6.13/ and http://www.cloudcompare.org/doc/wiki/in ... issonRecon). So we use the exact same parameters denomination (we don't expose all parameters though).
I don't know which algorithm Meshlab uses. If it's from the same library then it's maybe an older version of PoissonRecon. For instance the V4 had a "min octree" parameter: http://www.cs.jhu.edu/~misha/Code/Poiss ... /Version4/ - now renamed "full depth". And the "point weight" parameter has also been introduced in this version I believe.
In CC we are using the latest version of the PoissonRecon library (by M. Kahzdan - see http://www.cs.jhu.edu/~misha/Code/Poiss ... rsion6.13/ and http://www.cloudcompare.org/doc/wiki/in ... issonRecon). So we use the exact same parameters denomination (we don't expose all parameters though).
I don't know which algorithm Meshlab uses. If it's from the same library then it's maybe an older version of PoissonRecon. For instance the V4 had a "min octree" parameter: http://www.cs.jhu.edu/~misha/Code/Poiss ... /Version4/ - now renamed "full depth". And the "point weight" parameter has also been introduced in this version I believe.
Daniel, CloudCompare admin
-
foobarbecue
- Posts: 16
- Joined: Thu Mar 13, 2014 7:20 pm
Re: Poisson parameters correspondence between MeshLab and CC
I'm also confused about the "full depth" parameter. The documentation for poissonrecon is unclear:
"This integer specifies the depth beyond depth the octree will be adapted. At coarser depths, the octree will be complete, containing all 2^d x 2^d x 2^d nodes."
My guess is that the densest parts of the point cloud will be solved using a voxel grid at --depth (where a larger number means subdivided more times, i.e. smaller voxels), and the sparsest parts will be solved using a voxel grid at --fullDepth .
Or maybe I have --depth and --fullDepth backwards. I will look into the poissonrecon source code at some point.
The tooltips for the two parameters in CloudCompare are identical, which can't be right!
Depth beyond depth,
Aaron
"This integer specifies the depth beyond depth the octree will be adapted. At coarser depths, the octree will be complete, containing all 2^d x 2^d x 2^d nodes."
My guess is that the densest parts of the point cloud will be solved using a voxel grid at --depth (where a larger number means subdivided more times, i.e. smaller voxels), and the sparsest parts will be solved using a voxel grid at --fullDepth .
Or maybe I have --depth and --fullDepth backwards. I will look into the poissonrecon source code at some point.
The tooltips for the two parameters in CloudCompare are identical, which can't be right!
Depth beyond depth,
Aaron
Re: Poisson parameters correspondence between MeshLab and CC
Okay I fixed the tooltip issue in the code. However I kept Kazhdan's description for now (even if it seems that there are some typos in this description?!).
You're understanding of those parameters is globally right. The 'full depth' level is the level of subdivision until which all the octree cells will be represented in memory (even if there's no point or only a few points inside). Hence the 'the octree will be complete, containing all 2^d x 2^d x 2^d nodes' note).
Deeper, the octree will be 'adapted', i.e. only cells containing enough points will be subdivided (this is a upper boundary as all cells won't be subdivided to the same depth depending on their density).
The 'full depth' level is important for clouds with very low density areas (because if you don't subdivide the octree enough in those area, you would get a very coarse/ugly surface there).
So it's a kind of 'minimal resolution' level. The issue is that the memory used by a 'complete level' increases geometrically for increasing levels. So you can't obviously set the 'full depth' to a too big level (at level 8, there's already 256 * 256 * 256 = 16.777.216 cells and at level 10 you get a billion cells!). I don't know precisely the size of a single cell in memory, but I guess it's not 1 or 2 bytes ;). I also guess that the more cells you have, the longer the process will be.
But the more cells you have the nicer the result... so as often, you have to find the right balance.
You're understanding of those parameters is globally right. The 'full depth' level is the level of subdivision until which all the octree cells will be represented in memory (even if there's no point or only a few points inside). Hence the 'the octree will be complete, containing all 2^d x 2^d x 2^d nodes' note).
Deeper, the octree will be 'adapted', i.e. only cells containing enough points will be subdivided (this is a upper boundary as all cells won't be subdivided to the same depth depending on their density).
The 'full depth' level is important for clouds with very low density areas (because if you don't subdivide the octree enough in those area, you would get a very coarse/ugly surface there).
So it's a kind of 'minimal resolution' level. The issue is that the memory used by a 'complete level' increases geometrically for increasing levels. So you can't obviously set the 'full depth' to a too big level (at level 8, there's already 256 * 256 * 256 = 16.777.216 cells and at level 10 you get a billion cells!). I don't know precisely the size of a single cell in memory, but I guess it's not 1 or 2 bytes ;). I also guess that the more cells you have, the longer the process will be.
But the more cells you have the nicer the result... so as often, you have to find the right balance.
Daniel, CloudCompare admin
Re: Poisson parameters correspondence between MeshLab and CC
Thank you very much Daniel and Aaron for your answers and your reasoning and explaining.
I checked on ML user's forum and maybe you are right, Daniel: in ML an older version of the Poisson algorithm is used.
Thank you for your support!
I checked on ML user's forum and maybe you are right, Daniel: in ML an older version of the Poisson algorithm is used.
Thank you for your support!