campvis-public issueshttps://gitlab.lrz.de/CAMP/campvis-public/-/issues2017-12-03T17:14:26+01:00https://gitlab.lrz.de/CAMP/campvis-public/-/issues/6Add progress monitor support to processors2017-12-03T17:14:26+01:00Ghost UserAdd progress monitor support to processorsIt should be possible to observe a processors inner state, i.e. when it is beginning processing data, when it finishes and the progress in between. This would allow to add a progress bar to the GUI that displays it. This would also nicel...It should be possible to observe a processors inner state, i.e. when it is beginning processing data, when it finishes and the progress in between. This would allow to add a progress bar to the GUI that displays it. This would also nicely be integrated with ITK filters that can be monitored via observed->AddObserver(observer, itk::ProgressEvent). Another consideration is if one processors calls other processeors internally, then their progress should be added to the parent's progress.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/5Allow DataNameProperty for filtering of specific data types2017-12-03T17:14:26+01:00Ghost UserAllow DataNameProperty for filtering of specific data typesIt would be cool if the DataNameProperty (in READ mode) could automatically filter the shown DataHandles in the UI for the needed type (i.e. image data/geometry data/etc.). This could be done for instance by exploiting the CRTP-based reg...It would be cool if the DataNameProperty (in READ mode) could automatically filter the shown DataHandles in the UI for the needed type (i.e. image data/geometry data/etc.). This could be done for instance by exploiting the CRTP-based registration pattern once more to let data types generically register themselves during static initialization and receive an index that could be used for bit field-based filtering.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/4Improve line rendering of GeometryRenderer2017-12-03T17:14:26+01:00Ghost UserImprove line rendering of GeometryRendererThe `GeometryRenderer` is the bread-and-butter processor for rendering geometry. However, its implementation of rendering lines is still a hack:
- setting wireframe flag, sometimes it uses the wireframe color.
- the shading is done on ...The `GeometryRenderer` is the bread-and-butter processor for rendering geometry. However, its implementation of rendering lines is still a hack:
- setting wireframe flag, sometimes it uses the wireframe color.
- the shading is done on non-existent normal vectors
- linewidth is not set
Fix and clean the implementation and perhaps even merge with the fiber renderer (supporting on-the-fly creation of tubes or fake-tubes)https://gitlab.lrz.de/CAMP/campvis-public/-/issues/2Move closer towards an Entity-Component model2017-12-03T17:14:26+01:00Ghost UserMove closer towards an Entity-Component modelMove the framework design closer to entity-component-system model/design pattern. The original idea was that current AbstractData types (i.e. ImageData, GeometryData, ...) become Entities, that could get glued together to components. Tra...Move the framework design closer to entity-component-system model/design pattern. The original idea was that current AbstractData types (i.e. ImageData, GeometryData, ...) become Entities, that could get glued together to components. Transformation matrices, camera setup, lighting setup, and probably other stuff would also become entities, that would then define how to visualize the component.
Hence, the DataHandles in the DataContainer would store components.
Possible steps (besides others):
- Rename XyzData to XyzEntity
- Develop a component class that can nicely glue several entities together
- Get rid of complicated (non-primitive) properties: Use Entities (DataHandles) instead, which would make sharing much easier and further contribute to the Entitiy/Component concept
However, directly realizing a entity system like this would lead to quite complex code. This is the reason I did not implement it. Nevertheless, one should check whether it is possible to move closer towards this central game engine concept.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/3Move to Qt52017-12-03T17:14:26+01:00Ghost UserMove to Qt5Qt4 is sooo 2011 and Q5 is quite flawlessly nowadays. We should move CAMPVis to Qt5. However, this requires various adjustments in the CMake scripts.Qt4 is sooo 2011 and Q5 is quite flawlessly nowadays. We should move CAMPVis to Qt5. However, this requires various adjustments in the CMake scripts.