[vtkusers] How to fix PointData correspondence when point ids change?

[David E DeMarle]

> On Thu, Apr 22, 2010 at 10:42 AM, David Doria <daviddoria+vtk at gmail.com> wrote:
>> As David Gobbi explained a few days ago, some filters traverse the
>> cells (e.g. vtkExtractEdges) and hence change the point ids. If I have
>> an array (say a vtkFloatArray of the point normals) in the PointData
>> and the point ids get changed, the normals no longer correspond to the
>> correct point. How is this typically dealt with?

Filters that reorder the points should also be reordering the point
associated arrays. Otherwise the filter is buggy.
vtkDataSetAttribtues::CopyData() copies the N'th element from all of
the point associated arrays which makes it easier to do the copying
right.

Because of the arbitrary shuffling that frequently happens, an app
should never assume that the N'th point/cell in one vtkDataSet matches
the N'th point/cell in another. If you need to establish a
correspondence, you have to either make sure that nothing shuffles the
ordering on you, or you should use ID arrays.

So you are on the right track when you suggest the vtkIdFilter. Since
all correct filters move attribute data when they move points/cells
you can count on the content of the ID array even when you can not
count on the index.

PEDIGREE_ID and GLOBAL_ID arrays try to enforce the dependability of
these arrays even further. They make it so that if the filter knows
how to change these array contents correctly they can do so manually,
but rest of the filters that were not written to do so correctly do
the safe thing instead and remove them.