Yet Another Iteration Over Selections

This page summarizes a new design for changing the selection implementation in VTK and ParaView. This design proposes a replacement for vtkSelection and vtkExtractSelected* classes in VTK.

Drawbacks of the Current Design

The fundamental drawback of the current design is that it's not possible to combine multiple selection criteria together easily. The problem is two fold, not only is it not possible in vtkSelection to define such a selection-object, it's complicated to combine multiple extract-selection filters to extract such a combined selection.

Another issue is that it's not easy to add new selection types no the fly. Code in VTK needs to be changed everytime a new selection ContentType is added.

Implementation wise, vtkSelection uses overloaded SelectionList which is prone to errors and requires redundant checks and validations time and again.

Selection 3.0

This proposal, proposes three main classes:

• vtkSelection2 - this is the vtkDataObject subclass that will eventually replace the deprecated vtkSelection.
• vtkSelectionPredicate - this is superclass for a "criteria". This roughly corresponds to vtkSelectionNode in VTK 5.6.
• vtkBlockSelectionPredicate - same as vtkSelectionPredicate with the exception that it's used only to determine if a block in a composite dataset is selected.
• vtkGenericExtractSelection - this is the only extract selection filter that's needed in this new design unlike VTK 5.6 that has several filters e.g. vtkExtractSelectedIds, vtkExtractSelectedFrustum, vtkExtractSelectedRows etc.

vtkSelection2

The important API for vtkSelection2 is as follows:

class VTK_FILTERING_EXPORT vtkSelection2 : public vtkDataObject
{
public:

  ...

  // Description:
  // FieldType is used to determine the field association for the selection e.g.
  // cells, points, rows etc. It identifies what elements are being selected.
  // Accepted values are defined in vtkDataObject::FieldAssociations enum.
  vtkSetMacro(FieldType, int);
  vtkGetMacro(FieldType, int);

  // Description:
  // Get/Set the block-predicate. BlockPredicate is the predicate used to test
  // if a block in a composite dataset is selected or not.
  void SetBlockPredicate(vtkBlockSelectionPredicate*);
  vtkGetObjectMacro(BlockPredicate, vtkBlockSelectionPredicate);

  // Description:
  // Get/Set the predicate. This predicate defines what items are being
  // selected.
  void SetPredicate(vtkSelectionPredicate*);
  vtkGetObjectMacro(Predicate, vtkSelectionPredicate);

  ...

};

Issues/Rationales

Why not merely extend vtkSelection for backwards compatibility?

The APIs for vtkSelection and vtkSelection2 are going to be remarkably different. We are even changing the place of some attributes e.g. FieldAssociation. That'd make it confusing for users if we merged the two. Hence we keep them separate.

Why does vtkSelection2 have a FieldAssociation iVar?

With vtkSelection, when we moved the FieldAssociation iVar was moved from vtkSelection to vtkSelectionNode, the rationale was that we should be able to specify queries such as "in a graph, select all vertices that satisfy (A) , and select all edges that satisfy (B)". But selecting edges implies selection of corresponding vertices! So how do we deal with vertices not selected by (A) but get selected due to (B)? There's no toolkit level logic that can address such issues correctly. It's application specific. Applications should construct such heterogeneous element type queries as separate selections and combine then results as they deem fit.

Implementation-wise, combining such multi-element-type queries into one gives no performance benefit in general since we'd iterate over each element type individually anyways.

Hence, in this new design, a selection defintion specifies the one and only one type of elements to be selected.