[vtkusers] (no subject)

[Brian Davis]

At
https://www.vtk.org/doc/nightly/html/classvtkDecimatePolylineFilter.html#details

States
WarningThis algorithm is a very simple implementation that overlooks some
potential complexities. For example, if a vertex is multiply connected,
meaning that it is used by multiple distinct polylines, then the extra
topological constraints are ignored. This can produce less than optimal
results.

Is above warning code for  "crash at following lines"

  void Remove(vtkIdType vertexIdx)
  {
    this->Size--;
    (*(this->Vertices[vertexIdx].prev)).next =
this->Vertices[vertexIdx].next;
    (*(this->Vertices[vertexIdx].next)).prev =
this->Vertices[vertexIdx].prev;
  }

in vtkDecimatePolylineFilter.cxx class vtkDecimatePolylineFilter::Polyline

?

I have multiple distinct polylines housed in vtkPolyData.  I can seem to do
batch mode operations, *not that this documented anywhere mind you*,  with
vtkParametricFunctionSource for splines and vtkSmoothPolyDataFilter for
smoothing.... decimation errr not so much.

The goal which seems to work for some vtk classes (
vtkParametricFunctionSource  and vtkSmoothPolyDataFilter ) but not for
others (vtkDecimatePolylineFilter) is to house a network of lines connected
in a graph, but not a simple graph node to node, which do not represent
some geometry say like a circle or polygon, but rather a network of paths
and nodes.  Goal was to put in pipeline with optional decimation, smoothing
or spline, but then goes the crash at decimation.

Just what are those "potential complexities" and the bit about overlooking
say like bad memory access.  next has a pointer, but prev pointer not so
much (NULL).  Hey what about overlooking error checking and null pointers.
Clearly it seems to be overlooking that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtkusers/attachments/20181030/405195b4/attachment.html>