Problem Statement
Currently, ParaView (via VTK’s vtkSelection) can express selections of things that SMTK cannot represent:
- points within a model’s tessellation;
- cells within a model’s tessellation (these have semantic meaning in discrete models — but not parametric models — as inputs to operations that split or grow faces or edges);
- points/cells(i.e.,
VTK_VERTEX) within a model instance’s tessellation (these may have semantic meaning depending on the instance’s placement rule and the application) - points within a meshset
- cells within a meshset (these have semantic meaning for workflows that allow new meshsets to be constructed, since they effectively represent a new meshset or the input to an operation that may produce a related subset).
VTK selections are represented as a data object (vtkSelection) that holds a tree of selectors (vtkSelectionNode) that can be
- ID-based selections (an array of point or cell IDs)
- Frustum-based selections (all points or cells within a frustum)
- threshold selections (points or cells whose field data lies in a specified range)
- and more…
Currently we have a fixed “pipeline” that runs whenever ParaView’s selection changes. If the VTK selection content is a block selection, it maps the blocks to SMTK entities (this mapping may not be straightforward) and replaces SMTK’s selection with the result.
Also, we currently only render visual feedback if the VTK selection is a block selection but want to provide
- visual feedback in other cases (maybe all cases, but at least the ones above that have semantic meaning) and
- a method for SMTK operations to accept the semantically meaningful selections above.
Commonalities
Both proposals below would replace the fixed “pipeline” that runs on vtkSelection instances with one that allows each resource whose content is included in the selection to respond to the selection. Some patterns that might be useful for this more flexible pipeline:
- allow each resource to mark portions of the selection as consumed so that they are only used once
- provide some notion of priority so that workflows could enable (or disable) preferred actions on selection
- use SMTK operations to act on the VTK selection (not as input parameters, since vtkSelection cannot be expressed natively as an SMTK attribute). Applicable operations would be placed in an SMTK group and would run each time the VTK selection changed.
Proposal A — Selections become components
In this design, when a resource determines that a VTK selection has semantic meaning, it would construct a new component. Meshset cell selections would become new temporary meshsets; instance glyph-point selections would become temporary new instances. These new components would of course be added to (or replace) the current SMTK selection.
-
Pros:
- TJ has this mostly done.
- The pattern makes handling meshsets in particular easy.
-
Cons:
- Are selections really persistent? We aren’t planning for them to be serialized but making them components implies that they are.
- This requires the selection helper to know how the selection will be used ( in order to create the component), but that information might not be available until the user attempts to employ the selection (by providing it to an operation). Example: Say a users selects a subset of point placements from an instance. We can easily create a new instance with a “tabular” rule listing those points, but what other properties should be copied from the original instance? That seems application- or workflow-dependent. But once the user indicates which input of which operation, the intent and context are clear.
Proposal B — Selections populate attribute items
In this design, when a VTK selection is not a block selection (i.e., does not just result in a component selection), then it would be summarized and the summary communicated to the client. A custom attribute item view would access the summary and determine if it had semantic meaning. If so, users would be allowed to “copy” the selection into the item (or the view could do this by default). The item(s) themselves would be integer items holding point or cell IDs and potentially also correspondences to components on which those IDs came from.
-
Pros:
- This allows us to postpone interpreting the semantics of the selection until the user indicates the selection’s purpose.
-
Cons:
- The proposal is more vague than the one above.
- Not all operations would use every piece of information defining the VTK selection but we would have to transcribe it anyway.
Lifecycle
Deletion needs to be managed; how long should selections live? Who should be responsible for removing them from a resource?
Need to be careful with HoldReference="true" on operation inputs that are meant to hold selections as inputs if use-counts are going to be accurate and keep the selection alive.