copy-paste error in vtkCCSFindTrueEdges() of the vtkContourTriangulator algorithm
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
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.