Fix mesh_xsection #4
Conversation
|
@jbwhite Hold off on reviewing this for a moment -- it may not work with real meshes. |
|
@algrs OK -- did try to run one measurement using it, and it did not complete (did not troubleshoot why). |
|
Yep, there was a problem that was causing it to never terminate on a large and complex mesh. Rewrote a bunch more of it. Give it a read; most of it should make some sense at this point. |
|
@algrs When testing the values returned for this vs I've attached an output of results -- used |
|
The verts being in a different order is expected. Sorted is a bit weird.
They should be ordered in a ring around the body...
On Mon, May 22, 2017 at 4:45 PM Joseph White ***@***.***> wrote:
@algrs <https://github.com/algrs> When testing the values returned for
this vs master, I'm seeing the same values for vertices but in a
different order (on this branch they appear sorted by the first column).
I've attached an output of results -- used pdb.set_trace() to inspect the
values:
mesh_xsection_results.txt
<https://github.com/bodylabs/blmath/files/1020169/mesh_xsection_results.txt>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALh1OkarOYRQIDfeoqp684E1kUwUSC-ks5r8fPwgaJpZM4Ng75P>
.
--
- aw
|
|
These values look pretty reasonable, like what this bug fix would be
expected to change. You can show the lines in a mesh viewer and see if the
resulting rings are sane or not.
On Mon, May 22, 2017 at 4:45 PM Joseph White ***@***.***> wrote:
@algrs <https://github.com/algrs> When testing the values returned for
this vs master, I'm seeing the same values for vertices but in a
different order (on this branch they appear sorted by the first column).
I've attached an output of results -- used pdb.set_trace() to inspect the
values:
mesh_xsection_results.txt
<https://github.com/bodylabs/blmath/files/1020169/mesh_xsection_results.txt>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALh1OkarOYRQIDfeoqp684E1kUwUSC-ks5r8fPwgaJpZM4Ng75P>
.
--
- aw
|
| # This works because eulerPath mutates the graph as it goes | ||
| path = eulerPath(E) | ||
| if path is None: | ||
| raise ValueError("mesh slice has too many odd degree edges; can't find a path along the edge") |
There was a problem hiding this comment.
Raising an error here is a problem as much of the calling code expects that sometimes the result will fail to find a path.
The cross_section run function in measurements builds a collection of candidate_polylines and expects to get results where result.v is None:
for plane in self.planes:
raw_xs = plane.mesh_xsection(self.trimmed_mesh)
if raw_xs.v is None:
continue
convex_xs = convexify.convexify_planar_curve(raw_xs, flatten=True)
self.candidate_polylines.append(convex_xs)
There was a problem hiding this comment.
Will need a different way to break out of the loop too I think -- when I take out the raise this while loop just keeps running
| # Since we're willing to take away one connected component per call, | ||
| # we skip this check. | ||
| # if len(odd) > 3: | ||
| # return None |
There was a problem hiding this comment.
Is this comment still needed?
There was a problem hiding this comment.
It's relevant to the underlying algorithm; I think leaving it in there makes sense, explaining why we diverge from the algorithm named.
| else: | ||
| return "<open Polyline with {} verts>".format(len(self)) | ||
| else: | ||
| return "<Polyline with no verts>" |
Plane.mesh_xsectionwas a bit of a mess, and in particular it sometimes returned a "Polyline" that was actually a disordered set of lines, not an end to end connected ring. And it relied on a hack passing edges tobodylabs.mesh.topology.connectivit.remove_redundant_vertsinstead of faces and relying on a bug in it that fails to verify that the "faces" are actually Nx3. So. This is closer to a correct algorithm. And now with some real tests. And wrote it asPlane.mesh_xsectionswhich always returns a list ofPolylines, one for each connected component. Then wrote aPlane.mesh_xsectionthat mangles that result back into the jammed together singlePolylinethat it used to return.@jbwhite can you test that this still works with measurements?
@eerac just FYI.