When operating on datasets that vary over time, the new timesteps are often either the same or a linear transformation of the first timestep.
As of now, in the case of linear transformations, when a cell locator is utilized, you would have to rebuild the cell locator for the follow-up timesteps of a dataset.
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9149 introduces the concept of SupportLinearTransformation for cell-locators. This flag will be available for all vtkAbstractCellLocator subclasses except vtkOBBTree.
The implementation idea is the following:
When you call BuildLocator for the first timestep, you also ShallowCopy the initial points of the timestep.
At any subsequent timestep when you call BuildLocator, instead of re-building the cell locator, you extract the transformation matrix (and its inversion) from the subsequent timestep to the initial timestep using the Kabsch algorithm. The transformation matrix can be used inside any cell locator operation to query the first time timestep’s cell locator.
E.g. for the FindCell operation, the query point x is converted to xTrasform using the inverted transformation matrix back to the first timestep dataset’s space, then you get the correct sub-part of the cell locator that includes this cell, and then call EvaluatePosition using x.
One design choice that i would like your input for is if you think it would be better instead of adding this functionality to every cell locator, to create a new cell locator sub-class for every cell locator to support transformations.
- Use transformation information in existing classes
- Pros: no need to create and maintain new classes (there are 5 locator classes)
- Cons: special case code is embedded into simple code which adds maintainability complexity
- Create new sub-classes
- Pros: special case code is handled in classes specifically designed for this special case, and possibly in the future more transformation types could be supported
- Cons: new subclasses classes for each cell locator (there are 5 cell locator classes) add maintainability cost, and additional development cost
- Support Linear Transformations inside each existing Locator
- Create a new subclass for every locator to support linear transformation
Any further thoughts or input would be more than welcome!