Hi Rostislav,
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.
Thanks a lot,
Sascha
On 30/08/2014 12:17, Rostislav Khlebnikov wrote:
Hello Sascha,
I like the approach that you proposed. I will give it a shot and get
back at you either will pull request or more questions :)
Also, I have quite a specific use case which was the reason why I
started the whole "picking" thing. I need to pick some specific
"faces" of my objects.
So this will also let me test the flexibility of node picking
approach I will implement - this node picking will have to be
overriden by other observers in some cases.
All best,
Rostislav.
On 29/08/2014 17:31, Sascha Zelzer wrote:
Hi Rostislav,
DataNode selections based on picking in render windows is one of my favourite
missing
feature requests (the bug entry is really old). Great to see that you started
working on it!
I will first comment on the interaction issues and then on the selection
provider approach.
Picking interaction
-------------------
I discussed the issue with Christian and we think that the DisplayInteractor is
probably
not the best candidate to implement this. If you think your approach is worth
pursuing,
please publish a branch so we can discuss the code changes. But read on first
;-)
The FilterEvents() method was designed to pre-select events for which the
state-machine
should be notified at all. And the cause for ignoring the actions return values
is that
they are a legacy mechanism to decide if a state change should take place, but
that
mechanism was superseded by the introduction of "conditions".
The "picking process" (initiated by a mouse click, shift+click or similar)
looks like a
good candidate for being implemented as another mitk::InteractionEventObserver
class,
independent of the DisplayInteractor and without any state-machine logic. By
reacting
to mouse press and release events in the Notify() method, you could check if
there was
no drag between the two and then do the picking. This would work in parallel
with the
existing DisplayInteractor, so e.g. rotations in the 3d view should still take
place
(without picking because there was a drag).
I would propose the following architecture:
1. Create a mitk::PickingEventObserver sub-class of
mitk::InteractionEventObserver
in Core/Code/Interactions. For notification of picked data-nodes, use a
public member
of type mitk::Message<mitk::DataNode*> (similar to the mitk::DataStorage
class).
2. In org.mitk.core.services, register an instance of mitk::PickingEventObserver using
the us::ModuleContext class. Make sure the observer instance is initially
disabled.
Also use a service property named "name" with a value like "DataNodePicker"
when
registering the service.
3. To enable/disable picking in the application, we thought about adding a menu
entry
and/or toolbar button which retrieves the highest ranked
InteractionEventObserver
with (name=DataNodePicker) and calls Enable()/Disable() on it,
respectively. That
way, picking should work in all render windows.
DataNode selection provider
---------------------------
I would essentially go the route you already proposed. But instead of adding the
selection provider to the QmitkStdMultiWidgetEditor, we could add it to
QmitkAbstractRenderEditor such that it works for other displays as well. Again
an
initial draft how it could work:
1. Create a mitk::PickedDataNodeSelectionProvider in org.mitk.gui.common/src
which
inherits from berry::ISelectionProvider and returns a
mitk::DataNodeSelection
in its implementation of the GetSelection() method. To establish a
connection
with the picking process, the selection provider class should internally
track
the highest ranked mitk::InteractionEventObserver with (name=DataNodePicker)
and connect to its data-node messages after a dynamic_cast.
2. Add a new private "virtual berry::ISelectionProvider::Pointer
GetSelectionProvider() const"
method in QmitkAbstractRenderEditor which is called in the Init() method to
register the selection provider. The default implementation uses the new
mitk::PickedDataNodeSelectionProvider class.
Of course I am not sure if all this works out or if there are some unconsidered
issues. Any feedback to this proposal is welcome. We can also try to
organize/split
the work depending on your resources and willingness to tackle this. I think
this
could be an awesome new feature for any MITK based application.
Thanks,
Sascha
On 08/28/2014 07:56 PM, Rostislav Khlebnikov wrote:
Hi guys,
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?
Please answer some time soon.
Rostislav.
On 25/08/2014 22:09, Rostislav Khlebnikov wrote:
Just tried a simple implementation of this approach and it works
perfectly.
Would you agree with this change? Should I make a /yet another/
pull request? :)
Rostislav.
On 25/08/2014 22:03, Rostislav Khlebnikov wrote:
Hi guys,
I'm implementing the interactor to select some specific sub-objects but
I have a problem making it work with the display interactor.
Basically, I want the following quite natural behavior in 3D window:
- if a user clicks on the object of interest - it should be selected
- if a user clicks and drags - the view should rotate without
triggering the selection
Basically, I have a DataInteractor that processes mouse release events
in the state machine. What I do within it is the following:
Within FilterEvents method:
- On mouse press event, I record that dragging might have started and
return mitk::DataInteractor::FilterEvents, which as far as I understand
leads to returning true if there are any transitions for this event . In
this case, I have no transitions for that event, so it is being passed
to the vtk interactor style, which starts rotation.
- On mouse move event, I record that dragging actually started, with
the same return value as above.
- On mouse release event, I check if there was any actual dragging.
And if yes, I ignore the event by returning false so it would be passed
to the vtk interactor style to stop the rotation. But if not - there is
a transition and the event is accepted.
The problem is that the vtk interactor style does not get the mouse
release event in case a simple click was performed. Therefore it
continues rotating even though no actual dragging is performed.
What are your thoughts on how this can be fixed? What I see is that the
action's return value is not used at all (see
mitk::EventStateMachine::HandleEvent). Perhaps it could mean if the
event should be passed through, similar to FilterEvents?
Rostislav.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
