The vtkContourTriangulator algorithm is really nice. I'll likely have more to write, but in working with the algorithm, I noticed what looks like a copy/paste error in the update to the next edge which is using p2 twice. Here's the hunk of suspect code: ~~~ // Rotate to the next point p0[0] = p2[0]; p0[1] = p2[1]; p0[2] = p2[2]; p1[0] = p2[0]; p1[1] = p2[1]; p1[2] = p2[2]; v1[0] = v2[0]; v1[1] = v2[1]; v1[2] = v2[2]; l1 = l2; ~~~ Notice how the right column has p2 for the first six assignments. Just above the loop in which this code appears is the definition/initialization ~~~ v2[0] = p2[0] - p1[0]; v2[1] = p2[1] - p1[1]; v2[2] = p2[2] - p1[2]; l2 = vtkMath::Dot(v2, v2); ~~~ If the iteration is to remain consistent, with v2 becoming v1, then p2 becomes p1 and p1 (not p2) becomes p0. Attached is a patch in which I made some changes. The patch isn't from git, just a unified-diff. I'm not building the whole of VTK via git checkout, rather "patching" a library of sorts by introducing a routine of nearly the same name (irrelevant). [edge_rotate_copy_paste_error_vtkContourTriangulator.diff](/uploads/27f1e4ba1e6191185c484d0ceb92232d/edge_rotate_copy_paste_error_vtkContourTriangulator.diff) In the patch I've included some non-bug mods that one can take-or-leave. There are a few places where a Boolean is declared or inherent in the expression, and bit-wise-and (&) is used rather than logical-and (&&). I've seen bit-wise-and used quite a bit in the VTK code I've looked at, but in most instances the variable is declared as an "int", which I'd be fine with. Then there are a few cases where I moved a variable update and its associated range-check next to one another, e.g., ~~~ size_t midIdx = idx1 + 1; if (midIdx >= n) { midIdx -= n; } ~~~ because the optimizing-compiler programmer in me thinks it could save one or two machine cycles by leaving the result in a register, then perform the range limit immediately after. (But there are so many registers in modern CPUs, who knows?) What I would say about the vtkContourTriangulator's edge finding for non-closed segments is that I tried it. Although I didn't find it working as desired, it's always difficult to be conclusive when simply trying to get off the ground with model data and some sort of reasonable result. I figured my expectations were probably too great, i.e., that a generalized approach probably wouldn't achieve something better than what can be done by incorporating the known characteristics of the application. So, I moved on to closing open segments before passing the contours onto vtkContourTriangulator. Would the above mod have made a difference? Doubt it. It's a subtle effect, I'm guessing. I noticed there are some data sets for testing vtkContourTriangulator, but haven't gotten as far as working with those files yet.