Comments (5)
Hi Mike,
I think there are two things going on:
-
In the code, the voxel grid / octree discretizes the (scaled) bounding-cube, not the bounding-box, of the point-set (Lines 366-378 of PoissonRecon.cpp.)
-
In general, the reconstructed mesh should fit pretty snugly around the input points, so the bounding box of the points should provide a good proxy for the bounding box of the triangle mesh. However, in the case that the points do not sample a water-tight surface, the mesh may not close and the triangles can extrude out to the boundary of the working cube.
Taken in conjunction, this could create a situation where the reconstructed surface extends to the sides of the bounding cube, which (on the narrower sides of your point-set) can be far from the sides of the bounding box, giving you the larger scale factors you are seeing.
Looking at your output, that appears to be the case. (If you can view the mesh in wire-frame, these triangles will appear larger, as they are extracted from coarser cells of the octree.)
-- Misha
from poissonrecon.
Ah, makes total sense, thanks so much for the pointers! Especially to the lines of code where this scaling stuff is happening :)
from poissonrecon.
Hi @mkazhdan,
I'd like re-visit this issue. I am again trying to align the volume returned by the --voxel
flag into the same coordinate system as my input point cloud. But I am having problems aligning these two representations. My question here is informed by your previous post, which was very helpful.
For debugging purposes, I have transformed my point cloud exactly as suggested by the GetPointXForm
function (see here). After performing this transformation, my point cloud lies within the unit cube from (0,0,0)
to (1,1,1)
. The exact coordinate-wise min and max of my transformed point cloud is as follows:
Coordinate-wise min of transformed point cloud: [ 0.04545449 0.21783513 0.14679344]
Coordinate-wise max of transformed point cloud: [ 0.95454544 0.78216463 0.85320663]
This intermediate result seems correct to me. First, my point cloud has been transformed so that it lies entirely within the unit cube from (0,0,0) to (1,1,1). Second, the aspect ratio of the transformed point cloud is the same as in my original point cloud. Third, there is a symmetric amount of padding along each coordinate, so my transformed point cloud lies at the center of the unit cube, which is sensible. Fourth, there is almost exactly 5% padding on each side along the widest coordinate, which makes sense because I'm using the default value of 1.1x for the --scale
parameter. So far, so good.
However, I am having problems aligning the Poisson volume to the transformed point cloud without resorting to magic fudge factor constants. I would expect the Poisson volume to extend from (0,0,0) to (1,1,1), and for each voxel to be isotropic. But when I try to visualize the volume, I need to set its spatial extent using the following constants:
# note the magic fudge factor constants
poisson_func_extent_min_coords = array([0.00, 0.00, 0.15])
poisson_func_extent_max_coords = array([1.00, 0.78, 1.00])
Using these magic constants, the transformed point cloud and the volume line up almost perfectly. Here are some images of the transformed point cloud and the volume lining up almost perfectly. The zero level set of the volume, transformed to have the above spatial extent, is shown in green. The point cloud is shown in blue. The rgb lines are unit-length coordinate axes for xyz. Note that the blue and green representations agree almost exactly on silhouette boundaries. I am rendering with a standard perspective projection using the Mayavi contour3d
and points3d
functions.
But where do these magic constants come from? They do not seem to follow directly from the aspect ratio of the transformed point cloud. Is there some other scaling mechanism in the PoissonRecon code that would make the volume output by the --voxel
flag not extend from (0,0,0) to (1,1,1)?
from poissonrecon.
from poissonrecon.
Hi @mkazhdan, Thanks so much for your help. I figured out the problem. This issue was caused by a bug on my end.
When visualizing isosurfaces using Mayavi's contour3d
function, the extent
parameter actually specifies the spatial extent of the triangle mesh obtained using marching cubes, not the spatial extent of the underlying volume, which can lead to some confusion. In case anyone else is reading this and having similar issues, the following code is wrong:
poisson_func_extent_min_coords = array([0.0, 0.0, 0.0])
poisson_func_extent_max_coords = array([1.0, 1.0, 1.0])
poisson_func_extent = \
poisson_func_extent_min_coords [0], poisson_func_extent_max_coords [0], \
poisson_func_extent_min_coords [1], poisson_func_extent_max_coords [1], \
poisson_func_extent_min_coords [2], poisson_func_extent_max_coords [2]
# might be correctly or incorrectly scaled depending on the data in poisson_func
mayavi.mlab.contour3d(poisson_func, extent=poisson_func_extent, opacity=0.5, contours=[0.0])
But the following code is right:
X,Y,Z = mgrid[0:1:1j*poisson_func_size, 0:1:1j*poisson_func_size, 0:1:1j*poisson_func_size]
# will be correctly scaled regardless of the data in poisson_func
mayavi.mlab.contour3d(X, Y, Z, poisson_func, opacity=0.5, contours=[0.0])
Anyway, now I'm getting a perfectly aligned volume and point cloud with no magic constants. Yay! 😄
from poissonrecon.
Related Issues (20)
- question about ImageStitching HOT 4
- Disk-full errors are not correctly reported HOT 5
- Hardcoded /tmp files are created HOT 1
- PoissonReconClient segfault with `--multi 32` and default `--pDepth 5`
- PoissonRecon with Dirichlet 'creates multiple hulls' HOT 2
- Real-time monitoring memory HOT 2
- How does work the Point <Real, Dim> struct HOT 4
- Failed to build with default libjpeg,libpng, and libz. HOT 1
- How to get the number of points corresponding to an octree node HOT 8
- sln is incorrect HOT 1
- Normals - inward or outward? HOT 1
- Can we conclude a leaf node is fully inside the object if indicator function evaluations on its faces come out above the iso-value? HOT 4
- SSD Recon with Dirichelet boundary condition HOT 2
- PLY file not supported HOT 3
- Envelope Generation in PoissonRecon Integration with CloudCompare HOT 4
- PoissonRecon: Interaction between `--width` and `--depth` parameters is not well documented HOT 2
- using --exact in PoissonRecon.exe HOT 5
- A problem running with vs2019 HOT 1
- the program crushed with empty file write error message. HOT 2
- Segmentation Fault for create_from_point_cloud_poisson when n_threads is not 1.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from poissonrecon.