This is something for the rendering specialists. Any volunteers? Any comments on this?

The feature request is: picking a DataTreeNode by clicking on the object in a 3D (2D?) scene. This was requested by a MITK-User. Heres part of my reply-email:
Neuhaus Jochen wrote:

Hallo,

eine direkte Lösung kenne ich nicht. Ich würde folgendes versuchen:

mit einem vtkPropPicker das VTK-Modell picken. Dann bekommt man ein vtkProp und eine World Position.

Jetzt muss man alle mitk::Surfaces im Datenbaum/DataStorage durchgehen.
Vom Datenobjekt kann man die Geometry3D bekommen oder erst den Mapper und vom dem dann die Geometry3D. Geometry3D hat eine Funktion GetParametricBoundingBox(), die eine Boundingbox zurück liefert. Die kann man wiederum mit IsInside() fragen kann, ob der gepickte Weltpunkt drinnen ist. Das ist halt nicht eindeutig, wenn sich die Boundingboxen der Modelle überlappen.
Alternativ kann man von den Nodes die 3D Mapper bekommen und die haben wiederum eine GetProp() Methode, die ein vtkProp zurück liefert. Ich bin mir aber nicht sicher, ob der vtkPropPicker diese Props picken kann, denn der MITK-Renderingmechanismus verwendet intern so was wie eine PropAssembly, könnte also sein, dass immer nur die Assembly gepickt wird. Das müsste man mal ausprobieren.

Sascha is interested too, setting him cc (still waiting for volunteers)

This is something which would perfectly find into the new plugin architecture using the so called SelectionService. Supposing that the picking in the rendering window works, the StdMultiWidget would register itself at a global service as a "SelectionProvider" i. e. sending events when the user selected an object in the rendered scene. Other Functionalities/Plugins would register themselves at the SelectionService as "SelectionListeners" and would get notified of any selection event (coming from any widget which registered itself as a SelectionProvider). The selection event would provide information about the kind of selected object. The future DataManager/SceneViewer could than automatically select the corresponding node.

Writing such a SelectionService would be the next item on my Todo list anyway. Someone would have to write the vtk picking code for the mitk::RenderWindow classes.

Just my thoughts about how this could work...

A nice feature request for the Bug Squashing Parties.

Accept bug

assigning sascha

assignement was wrong, assigning to Alex

Bug Squashig Party results (by Alex and Lena)

• vtk picking initiated by pressing "p" already works for most data types
• it does not work for mitk::PointSet
• to check if a DataTreeNode corresponds to the picked prop, the GetProp() of

the corresponding mapper is called

• CHALLENGE: prop can be an assembly: need to check children?
• matching a picked prop to a DataTreeNode workds (has been implemented and

tested in a test function)

Question: Who has an example of an assembly that can be picked?

Will look into this (this or a similar feature is required for new interactive liver resection, cf. T2251)

A basic interface for object picking has been implemented as documented in T2448. The further requirements / ideas described above can be built on top of this interface.

vtkScenePicker may be interesting here to improve performance (needs to be checked...)

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

@Stefan,Jasmin: just as a starting point. I don't mind if you close this bug and file a new one with a clear feature request.

Stefan, can you have a look at this bug again? And if there is a additional information for your project can you move it to your bug?

Hi guys, any news on this front?

CC from my message to mailing list:

I made some changes to my MITK fork and I wonder if you might be interested. Basically, I modified DisplayInteractor to support simple clicks, as well as ctrl and shift clicks that find the picked node using the basic picking interface. This can be enabled/disabled by using the MouseModeSwitcher with a new "Picking" mouse mode.

The only thing that needs to be changed is access to some selection provider which would inform all the views about selection change. I would need some help regarding how to make this properly. Should DisplayInteractor expose some picking events and the QstdMultiWidgetEditor would listen to? Then this editor should be a selection provider itself. Is this the way to go?

Copy from the mailing list:

On 09/10/2014 02:41 PM, Rostislav Khlebnikov wrote:

Hi guys,

I have implemented the first version of data node picking. I have opened a pull request to discuss this https://github.com/MITK/MITK/pull/78.

Awesome. I skimmed over the changes and it looks great so far. I need to do a more thorough review / testing cycle though.

Things that are missing or are bothering me:

• Button for turning picking on/off

We could probably take care of that next Wednesday.

• To initialize service tracker for PickedDataNodeSelectionProvider which is a part of org.mitk.gui.common plugin, I need a us::ModuleContext. For now I couldn't find a better way than us::ModuleRegistry::GetModule(1)->GetModuleContext() (copied from Plugins\org.mitk.core.services\src\internal\mitkPluginActivator.cpp), which I find very disturbing.

Yes, this is a anti-pattern. You can put a US_INITIALIZE_MODULE(...) macro call in one of the plug-ins cpp files. See for example org.mitk.gui.qt.eventrecorder/src/internal/InteractionEventRecorder.cpp . You can then just call us::GetModuleContext() anywhere in the plug-in code.

• Small stuff for cleaning, such as c++11 keywords

I understand why they are nice to use during development. However, could you please compile without C++11 support and create a new pull request (so we don't have a commit removing the C++11 stuff in the history) ?

Additional stuff:

• I modified Data Manager view to update the tree view selection based on the selection changed events coming from other selection providers. The picking selection provider also updates its selection in a similar fashion.

Sounds good. I will look into it.

Overall, this seems to work pretty well for me.

As an additional thing, I have implemented my custom picking observer which selects some face sets on my poly data objects. This requires turning off the default picking provider, which again made me use the disturbing GetModule(1) construct. Nevertheless, it worked out pretty well. This custom picking was also the reason why I separated the picking behavior into two parts. First, the PickingEventObserver whose function is to react to correct events, track if any dragging was performed, and call the virtual methods to forward the picking events (PickOne for simple click, PickAdd for shift-click and PickToggle for ctrl-click) for processing to subclass. Second, its subclass, the DataNodePickingEventObserver which overrides these virtual methods to actually recover the data node and send the events. In my code, I also subclass PickingEventObserver but instead of picking data nodes, I pick face sets on my poly data.

This sounds very nice. Please give us a couple of days for the detailed review.

I reviewed the changes and they look good to me.

However, I couldn't compile the code due to the C++11 keywords. Do you mind removing them and updating the pull request? And also rewrite it such that it doesn't contain duplicated commits. It looks like you rebased your original branch on a newer master and then merged in the non-rebased branch again.

Take a look at the pull request - will this do the job?

Thanks, I started the integration work.

I realized that there is a "pickable" property which is checked for true. Do you specify this property for all your data nodes which you want to be pickable or did you use another approach?

Yes, I added the pickable property for all nodes that need to be picked in my "business logic" code.

User zelzer has pushed new remote branch:

bug-1447-Picking-of-DataTreeNodes-via-vtkPropPicker

Updating target milestone.