Skip to content

Draft: Trajectory Actor and Pipeline Rework

Christoph Fischer requested to merge devel_trajectory_rework into master

This merge requests reworks the trajectory actor and the pipeline to address various bugs and problems, and changed the pipeline architecture. It features

  • Interface for point generating sources. Previously, the trajectory actor itself implemented seeding points on several hard-coded sources, which had to be actors. This merge request introduces a point generating source interface, which classes can inherit from to register themselves to the point source factory. They have to implement methods to build a string to be inserted into the data request for generating points, and generate the points based on the received string. The interface itself is not a data source, but a data source can be generated given an interface.
  • Interface for point filters: These filters take a MPoints data item as input (either from other point filters or from point sources) and output themselves a MPoints data item. These filters can be registered in a factory to be available via a UI dialog.
  • Interface for trajectory filters: Similar to point filters, they take a trajectory selection and output a trajectory selection. Also a factory is used to register these filters.
  • Previously, the trajectory actor kept track of all the data requests emitted and which one already have finished. When all requests are finished, the data is rendered. This is in the new pipeline obsolete, as the MTrajectoryPipeline both handles the current state of the pipeline, but also acts as a data source with all requested data (normals, auxiliary data...) as parents. Therefore, a data request is only completed, once the entire pipeline has finished.
  • Added UI classes for the filters to be more modular.
  • The pipelines are set up dynamically based on the filters selected in the UI. This system has several advantages: Not all filters have to be added to the pipeline (less prone to bugs), and arbitrary many filters of the same type can be added to one pipeline. To achieve that, these filters generate a unique ID for their data request key. This rework removes lots of code from the pipeline configuration class, as the pipeline does not have to manually programmed on program start.

Resolves #414, resolves #412, implements #299, resolves #223, resolves #428, resolves #409.

Edited by Christoph Fischer

Merge request reports