Notes |
|
(0029833)
|
Andriy Fedorov
|
2012-12-06 09:03
|
|
Attached are the models that together with the script below allow to reproduce the problem:
import vtk, sys
r1 = vtk.vtkSTLReader()
r1.SetFileName(sys.argv[1])
r1.Update()
r2 = vtk.vtkSTLReader()
r2.SetFileName(sys.argv[2])
r2.Update()
inter = vtk.vtkBooleanOperationPolyDataFilter()
inter.SetOperationToDifference()
inter.SetInputConnection(0, r1.GetOutputPort())
inter.SetInputConnection(1, r2.GetOutputPort())
inter.Update()
w = vtk.vtkSTLWriter()
w.SetInputConnection(inter.GetOutputPort())
w.SetFileName(sys.argv[3])
w.Update() |
|
|
(0031949)
|
Dave DeMarle
|
2013-12-16 13:50
|
|
Cory, can you investigate and see what the problem might be? |
|
|
(0032048)
|
Cory Quammen
|
2013-12-23 15:57
|
|
I am able to reproduce this error. Investigating. |
|
|
(0032112)
|
Cory Quammen
|
2014-01-02 14:04
|
|
I have tracked the problem down to the vtkDelaunay2D filter. This filter is supposed to treat line cells in the input set via SetSourceConnection() as edges that must appear in the output of the Delaunay triangulation, making the output in this case not necessarily a true Delaunay triangulation but a constrained Delaunay triangulation instead. In some cases, not all required edges are present in the output of the Delaunay triangulation. I'm investigating why. |
|
|
(0032114)
|
Cory Quammen
|
2014-01-02 14:13
|
|
Also, I have attached an input file (test_delaunay_input.vtk) containing a polydata with points and line segments derived from the original test file from Andriy. This file causes the constrained Delaunay triangulation within vtkDelaunay2D filter to fail (output in delaunay_output.vtk). The test program that produced the output is attached. When compiled, one can run it with
./Delaunay2DTest test_delaunay_input.vtk delaunay_output.vtk
to get the attached output file. |
|
|
(0032118)
|
Cory Quammen
|
2014-01-02 17:13
|
|
vtkDelaunay2D is bailing out on restoring the constraint edges when failing to find a neighboring cell in the neighborhood of a constraint edge. This is likely because the triangles produced by the Delaunay triangulation are not wound in a consistent ordering in the test input I posted, which seems like a bug. |
|
|
(0032128)
|
Cory Quammen
|
2014-01-03 12:03
|
|
I think the underlying problem is that the Delaunay triangulation for the box geometry results in very long and thing triangles, which is known to cause problems with the Delaunay algorithm. A solution is to insert new points into the geometry to make the output triangles not quite as thin.
As a workaround, I recommend subdividing at least the cube.stl geometry using the vtkLinearSubdivisionFilter. By setting the NumberOfSubdivisions in the vtkLinearSubdivisionFilter to 2, I can get good results. See the image file SubdivisionResults.png I posted. |
|
|
(0036275)
|
Berk Geveci
|
2016-07-06 16:48
|
|
Setting to status of bugs that have not been updated in the last year to expired. Please re-open if still important. |
|
|
(0037296)
|
Kitware Robot
|
2016-08-12 09:55
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page. |
|