Fix vtkCutter and add test for ContourLoopExtraction

[Jo-Byr]

Context

vtkCutter yields invalid results if the plane intersects a point of the cut mesh. This is visible on vtkContourLoopExtraction's example where the loop extraction returns 8 loops (visibly 3: pink, green, pink but each actually has multiple layers under).

Results

By properly handling cases where the plane intersects a point, we can fix the issue and have only 2 loops (red and green):

Changes

Properly differentiate the 3 cases: negative sign, null sign (on plane) and positive sign

Dedupe points, result of a same point being counted twice.

For the green triangle, intersected in one of its vertices by the red plane, 2 edges will be counted as intersected on the same position.

Added a non-regression test on ContourLoopExtraction

Modified ContourLoopExtraction example's parameters to fit with the model's bounds.

PR Checklist

• GitHub Actions CI passed: semantic-release commit messages, lint, and tests
• Test coverage added
• Documentation and TypeScript definitions are updated to match these changes

[finetjul]

Does it mean the VTK C++ implementation also has the problem ? If so, please report a bug in VTK

[Jo-Byr]

Does it mean the VTK C++ implementation also has the problem ? If so, please report a bug in VTK

I didn't look into the C++ implementation but it does not produce this invalid result, I used a local python vtk as a truth test.

[sankhesh]

LGTM with a couple of questions

[sankhesh]

This new sign()-based crossing detection is definitely better than what we had before but I'm curious what would happen if all points of the cell are exactly on the cut plane? I'd assume firstPointIdx remains null. It might be a good test case too.

[Jo-Byr]

I tested with a cube and it works fine with a cut plane in the same plane as one of the faces since their points will be discovered when testing the intersection of other cells that share these points.

The only case where I can see it failing is a single cell whose points are not shared with any other cell, that is colinear to the plane. But even if we added a fallback firstPointIdx = firstPointIdx ?? 0 it would get caught by allPointsSameSide.

[finetjul]

Does it mean the VTK C++ implementation also has the problem ? If so, please report a bug in VTK

I didn't look into the C++ implementation but it does not produce this invalid result, I used a local python vtk as a truth test.

Isn't the vtkCutter JS implementation a port of the VTK C++ implementation ? Maybe it would be wise to check how it differs...

[Jo-Byr]

Isn't the vtkCutter JS implementation a port of the VTK C++ implementation ? Maybe it would be wise to check how it differs...

From my understanding of the C++ implementation, it has a special implementation for plane cutting with vtkPlaneCutter, itself going into vtkPolyDataPlaneCutter if the inputData is a polydata, and a generic DatasetCutter method for cutting a vtkPolyData by something else than a plane.

This method itself uses vtkContourHelper to get the contour out of the evaluated cutter function on every point of the input data that indirectly falls back to vtkTriangle::Contour that finds intersection points along edges and draws a line between them.

It all relies on the cut scalars indirectly. For plane cutter it uses a triple state too:

// Point is either above(=2), below(=1), or on(=0) the plane.
// NOLINTNEXTLINE(readability-avoid-nested-conditional-operator)
*inOutItr = (eval > zero ? 2 : (eval < zero ? 1 : 0));

I don't know if it's generic in C++ but it seems a natural approach to me.