-
Notifications
You must be signed in to change notification settings - Fork 427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
axis-aligned bounding box around output triangle mesh is larger than expected #21
Comments
Hi Mike, I think there are two things going on:
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 |
Ah, makes total sense, thanks so much for the pointers! Especially to the lines of code where this scaling stuff is happening :) |
Hi @mkazhdan, I'd like re-visit this issue. I am again trying to align the volume returned by the For debugging purposes, I have transformed my point cloud exactly as suggested by the
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 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:
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 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 |
Hi Mike,
I’m afraid I’m not sure where the magic factors come from. (There should be no additional scaling on my end.)
It does seem strange however, that the “0.78” and “0.15” factors line up pretty closely with max y and min z values...
Can you share the point-cloud you are using?
…-- Misha
From: Mike Roberts [mailto:notifications@github.com]
Sent: Tuesday, August 22, 2017 12:55 AM
To: mkazhdan/PoissonRecon <PoissonRecon@noreply.github.com>
Cc: mkazhdan <misha@cs.jhu.edu>; Mention <mention@noreply.github.com>
Subject: Re: [mkazhdan/PoissonRecon] axis-aligned bounding box around output triangle mesh is larger than expected (#21)
Hi @mkazhdan <https://github.com/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 <https://github.com/mkazhdan/PoissonRecon/blob/03604f92a9b0588c030baf654e1bac1d93671ad8/Src/PoissonRecon.cpp#L376> ).
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 perfectly. Here are some images of the transformed point cloud and the volume lining up perfectly. The zero level set of the volume, transformed to have the spatial extent specified above, is shown in green. The point cloud is shown in blue. Note that the blue and green representations agree almost exactly on silhouette boundaries. The rgb lines are unit length coordinate axes for xyz. I am rendering with a standard perspective projection using the Mayavi contour3d and points3d functions to handle the rendering.
<https://user-images.githubusercontent.com/2341965/29548710-d6514250-86b7-11e7-96c6-f61850f5626a.png>
<https://user-images.githubusercontent.com/2341965/29548728-fc02f50c-86b7-11e7-9a13-f3b7d6a5413e.png>
<https://user-images.githubusercontent.com/2341965/29548806-9abdeb70-86b8-11e7-8b9b-b6e6a406e30a.png>
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)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#21 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AKXc5emB9ea7okCEZttNVw_sIbgjqsJ3ks5sal8ugaJpZM4K-iM0> . <https://github.com/notifications/beacon/AKXc5W_bnCGp46YI5EkNFxQH7xipZds4ks5sal8ugaJpZM4K-iM0.gif>
|
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
But the following code is right:
Anyway, now I'm getting a perfectly aligned volume and point cloud with no magic constants. Yay! 😄 |
Hello there,
I have a question about the
PoissonRecon
command-line program. I'm interested in sampling the output voxel grid (i.e., output by the--voxel
flag) over the output triangle mesh. In other words, I'd like to color each vertex of the output triangle mesh according to the corresponding value in the voxel grid.I am aware that the output voxel grid sampled over the output triangle mesh should always be 0, because the triangle mesh is exactly the 0 level set of the voxel grid. But I still want to be able to sample the voxel grid in this way, because I ultimately want to want to compute derived quantities over the voxel grid, and sample these derived quantities over the triangle mesh.
Sampling the voxel grid in this way requires care, because the voxel indices need to be mapped into the coordinate system of the output triangle mesh.
In my code, I assume that the axis-aligned bounding box (AABB) of the voxel grid is exactly 1.1x the size of the AABB of the input point cloud along each dimension (i.e., I am using the default value for the
--scale
parameter). I also assume that the AABB of the voxel grid has the same center as the AABB of the input point cloud. Together, these assumptions uniquely determine the mapping from triangle mesh coordinates to voxel indices.These assumptions also seem to imply that the AABB of the output triangle mesh should be at most 1.1x the size of the AABB of the input point cloud along each dimension. But I am finding that this isn't the case. I am getting a larger-than-expected AABB for the output triangle mesh. In my particular case, the size of the of the output triangle mesh's AABB along each dimension, relative to the input point cloud's AABB is
[ 1.02068782 1.16858709 1.34913611]
. Note that the relative size of the output triangle mesh's AABB is noticeably larger than the maximum expected relative size of 1.1x along the last two dimensions.Is the voxel grid's AABB indeed 1.1x the size of the input point cloud's AABB? If so, where are these output vertices coming from that are so far outside the AABB of the voxel grid? I understand that
PoissonRecon
implements marching cubes, but as far as I am aware, marching cubes only produces triangles that are interior to a voxel grid (i.e., marching cubes does not extrapolate).This behavior is potentially problematic, because it suggests that I'm not aligning my voxel grid and my output triangle mesh correctly.
I'm using PoissonRecon version 9.0 on Mac, and I'm invoking it as follows:
In case it's helpful, I've uploaded my input point cloud and output triangle mesh below.
Input point cloud: https://www.dropbox.com/s/ybhjsj3iejiix7c/pset_mvs_si.ply?dl=0
Output triangle mesh: https://www.dropbox.com/s/8oqe0jtkxujohqi/poisson_surface_si.ply?dl=0
Cheers,
Mike
The text was updated successfully, but these errors were encountered: