Page MenuHomePhabricator

Design new enhanced PointSetVtkMapper3D
Closed, WontfixPublic

Description

Applying Properties and management of underlying VTK Objects is messed up in the current PointSetVtkMapper2D. Mathias and I will rewrite it to be more flexible and work as expected.
Our design is as follows:

PointSet stores a PointData for each Point. In PointData, different types of points can be specified (and other properties too). These types/properties should be used for visualization - use different models for different types for example.

Changes to PointData and to Properties should applied to the vtk objects immediately. This means that the mapper has to keep track of all vtk sources, properties, filters that affect the display of the PointSet.
In Detail:
Each Point in a PointSet has an ID.
The Mapper has a map: ID -> Pointer to vtkActor for that point
And following maps:
ID -> SphereSource*
ID -> CubeSource*
ID -> ConeSource*
ID -> CylinderSource*
And a pointer to the Tubefilter that generates the contour.

A "PointTypeLookupTable" describes which model should be used for which pointtype.

Whenever a PointData changes(, is added, deleted): the mapper looks up the ID in the Source maps that corresponds to the entry in the PointTypeLookupTable. If nothing is found, a new source is created and added to the map.
Then all other maps are searched and if an entry is found (=point existed before but type changed), it is deleted. The same applies to the pointsize property

In addition, a ColorLookupTable, OpacityLookupTable and VisibilityLookupTable can be used to change color, opacity and visibility per point. If they (or the global color, ... properties) change, the Point ID is searched in the ID->vtkActor map and the vtkProperty that belongs to the vtkActor is changed accordingly.

If contour properties are changed, the tubefilter (contoursize), tube actor (contourcolor,...) or tubepolydata (points added, removed, close contour) is updated. The contour can not have different properties per point, that's the scope of a VesselTree datastructure & mapper.

This will allow that different points are displayed as different 3D models, can have different colors, opacities, visibilities, point sizes and can change all these aspects through property changes and that the changes are visible immediately.

Any additions/comments/ideas?

Event Timeline

The new design will need more memory per point than the old one. This could be a problem for very large pointsets. Therefore we will keep the old PointSetVtkMapper3D as it is and create a new one called "EnhancedPointSetVtkMapper3D" which will contain the new features.

A first work in progress version has been commited in revision #15722.

first incomplete but working version committed in revision #15924.

management of vtk objects works, but needs to be tested thoroughly.

current todos:

//TODO test different pointSpec
// TODO "line width" "show contour" "contourcolor" "contoursize" "close contour" "show label", "label"
// TODO "show points" vs "visibility"  - is visibility evaluated at all? in a superclass maybe? 
// TODO create lookup tables for all properties that should be evaluated per point. also create editor widgets for these lookup tables!
// TODO check if property changes and pointset changes are reflected in the renderwindow immediately.
// TODO check behaviour with large pointsets
// TODO check for memory leaks on adding/deleting points

r16422: Added data and property template classes for generic lookup-tables. Also added a sample template instantiation to mitkProperties.cpp/.h for float values.

These classes (mitk::GenericLookupTable and mitk::GenericLookupTableProperty) are intended to be used for specifying classes of parameters (size, shape, color, etc.) for the PointSet mapper (as described before). For each kind of parameter, a GenericLookupTableProperty should be added to the DataTreeNode of the PointSet by the user. It should then be extracted by the mapper, which then can configure the visual properties of the rendered points accordingly.

The PointData struct associated with each point in the PointSet has the entry "id" which could be used as key for the lookup table(s). (Alternatively, the "PointSpecType" could be used.)

The lookup-table classes are still very basic and have not been tested yet. mitk::GenericLookupTable is just a very simple (MITK) wrapper class for std::map.

The following implementation details are still missing and should be added (at least!):

  • Write/ReadXMLData (both classes)
  • operator= for assigning one lookup table to another (deep copy)
  • operator== for comparing one lookup table with another

should be finished for release 0.12

changing bug name to reflect bug content.

Ingmar reported, that he has been using the EnhancedPointSetVtkMapper3D for some time now. The features that are currently implemented work fine, so it should be possible to include the current version in the release (declaring it as "Experimental" and work in progress).

removing this bug from the 0.12 milestone, because the current version is ready for 0.12 as "experimental". Adding the missing features is planned for a later release.

r17024: Added class documentation; removed out-commented code copied from standard mapper; removed unused methods

Relocate bug to MITK / Rendering

Sven is ill, I'll continue with this bug.

I added a mitkSpecializeGenericLookupTable macro to mitkGenericLookupTable.h to be able to create specific lookup tables (analogous to the macro in mitkGenericProperty.h).

Then I added the files mitkLookupTables.h and mitkLookupTables.cpp to define and instantiate the following lookup tables: BoolLookupTable, FloatLookupTable, IntLookupTable and StringLookupTable.

I fixed some compilation errors in mitkGenericLookupTable.h - mostly const correctness problems.

I believe, mitk::GenericLookupTableProperty is unnecessary, if we use the existing mitk::GenericProperty with MyLookupTable::Pointer as template parameter (the two classes are basically identical save of the member definition: ValueType m_Value versus ValueType::Pointer m_Value)

Therefore, I changed the LookupTableProperty definitions in mitkProperties.h &.cpp from
mitkSpecializeGenericLookupTableProperty(FloatLookupTableProperty, FloatLookupTable);
to
mitkSpecializeGenericProperty(FloatLookupTableProperty, FloatLookupTable::Pointer , FloatLookupTable::New());

Lastly, I adapted the EnhancedPointSetVtkMapper3D to look for and evaluate a BoolLookupTableProperty as "visibility" and a FloatLookupTableProperty for "opacity".
The example is working, I got a pointset with different opacity values per point :-) See attached screenshot.

screenshot showing per point opacity values

OpacityLookupTable-Example.jpg (973×938 px, 36 KB)

Mathias, Sven, can you please comment!

Discussed this with Jochen: we don't think this feature is very relevant for 1.0, as it is still work in progress and has a number of open todos / questions.

(NEXT COMMIT) Added possibility to color points with individual colors. It can be used with the new property "colorLookupTable". This mitk::LookupTable associates the point index to point color.

[SVN revision 25860]
FIX (#1692): added color lookuptable

bug assigned to Markus, he's still working on it.

what is the status of this bug?

Markus F. has already committed his changes and has completed the work on this bug. Sven, can you take the bug again and see what's missing? Thank you

@Jochen: It seems like you worked a lot on this bug and nobody knows the current status. Can you please summarize the status? Maybe we can just close it.

The basic mapper is complete, but i don't know if all properties of the old point mapper are supported by the new one. It is certainly not yet used as default mapper and therefore not extensively tested.

This new mapper has the potential to be both more performant and more feature-rich than the old mapper. The old mapper has serious performance issues for large pointsets.

Looking at the bug history, no one seems to need the new mapper, so maybe it doesn't need to be worked on any more. Would be a shame, many people put a lot of effort in the mapper and it is close to be able to replace the existing mapper.

I would suggest to test it thoroughly, check if it needs to support more standard properties for pointsets and then use it as a replacement for the current pointset mapper.

Sandy, can you have a look at this bug? If I'm right, you redesigned a PointSetVtkMapper3D but which on?;o) Can you please check if this bug can be closed or if there are some relevant features (new bug).

I worked on the PointSetVtkMapper2D.

I think it might be worth to have a closer look on the EnhancedPointSetVtkMapper3D in order to estimate whether it can replace the PointSetVtkMapper3D without an additional massive workload.

kislinsk claimed this task.
kislinsk added a subscriber: kislinsk.
This task was automatically closed because it wasn't updated at least since July 2016 (over 2 years). Please re-open this task if you think that it is still relevant. This most probably means that you will resolve it.