Page MenuHomePhabricator

Direct geometry manipulation widget
Closed, ResolvedPublic

Assigned To
None
Authored By
maleike
Jan 11 2016, 11:35 AM
Referenced Files
F1286: gizmo-datamanager.png
Jan 13 2016, 6:53 PM
F1285: gizmo_2.jpg
Jan 11 2016, 11:40 AM

Description

I would like to add a direct geometry manipulation object for 3D interaction (sometimes refered to as "gizmo"). See attached screenshot for the visual representation.

The object will support the folloing interactions:

  • dragging a central sphere (not visible in screenshot): move the object's center freely on a plane parallel to the camera plane
  • dragging one of the axes: move the object along the used axis
  • dragging one of the cones at the end of an axis: scale the object (equally in all directions)
  • dragging one of the circles: rotate the object around the corresponding axis

Some features would be logical extensions but are not yet implemented:

  • scaling along a single axis (perhaps with a modifier-key during dragging)
  • rotating around the camera's view axis (trigger?)
  • rotating freely around the center:"pick a point on a sphere" interaction as for the VTK camera at the moment, but movement applied to the object, not the camera (would require a distinction between this mode and the regular camera rotation mode when the user clicks in the 3D background. A good option could be the distance to the object's center, where any click inside the gizmo rotates the object, any click outside rotates the camera)

In a first version, this object has been developed in a module that contains a BaseData sub-class and a DataInteractor sub-class. I requested the

Needs_Core_Modification?

in order to get an opinion whether this feature could/should be part of core. In my opionion it would be well-placed there.

Event Timeline

Attached a screenshot.

PLUS: I forgot one detail: Would anyone oppose to the name mitk::Gizmo, providing a good alternative (with a reasonable length for the class name)?

gizmo_2.jpg (460×545 px, 30 KB)

User maleike has pushed new remote branch:

bug-19489-3d-direct-geometry-manipulation-gizmo

User maleike has pushed new remote branch:

bug-19489-3d-gizmo-experimental

(In reply to Git Admin from comment #3)

User maleike has pushed new remote branch:

bug-19489-3d-gizmo-experimental

This branch contains a first attempt on undo/redo, but does not yet work well (groups all manipulations into a single one).

For your consideration: I'll still add undo/redo functionality and see if I can add 2D interaction without too much effort.

We discussed the gizmo yesterday, and long story short, we are of course excited about the contribution :). But, there are also a few, well, let's call it "minor concerns":

  • 2D interaction/mapping of the gizmo
  • Usability might be too cryptic (especially different operations which depend on where one clicks an arrow)?
  • Will it be configurable like "only scaling is allowed for a certain object"
  • We need something that really uses the gizmo like a plugin, otherwise it would be "just that code in the Core nobody knows about" but we would have to maintain :)

(In reply to Stefan Kislinskiy from comment #6)

We discussed the gizmo yesterday, and long story short, we are of course
excited about the contribution :). But, there are also a few, well, let's
call it "minor concerns":

Thanks for your positive feedback! I'll comment on your minor concerns in context:

  • 2D interaction/mapping of the gizmo

Has already been implemented since I have had a side-discussion about this. Works practically the same except for rotations. I could not figure out a meaningful visualization for the rotation "rings" which in most cases coincide with the object axis (at least before interaction/modifications to the geometry). Translation and scaling works, however. It can also be controlled via a property whether the 2D representation shall be shown or not.

  • Usability might be too cryptic (especially different operations which

depend on where one clicks an arrow)?

Actually, I think that usability of the concept is quite well. Seems that multiple 3D manipulation software uses this kind of widget. I based the idea on the images in http://www.unknownroad.com/publications/SketchWidgetsEG08.pdf

Regarding the implementation of the concept (i.e. can we work well with the thing or is it too sensitive regarding picking precision etc.) we should gather some feedback. I know that in the context of my current project there will be people using the gizmo and I'd suggest to give it some time to work out whether usability is ok.

  • Will it be configurable like "only scaling is allowed for a certain object"

I added a flags to the object that work like on/off switches for

  • translation
  • rotation
  • scaling

These are a first step towards configuration. More granular configuration can be imagined, but should be motivated by a real use-case / user.

  • We need something that really uses the gizmo like a plugin, otherwise it

would be "just that code in the Core nobody knows about" but we would have
to maintain :)

Ok. I could provide a simple view that allows adding this gizmo to a selected node. This could perhaps also be implemented as a context menu check item for Data Manager. Anyway, I'll interpret your comment as "we should put it in Core if it is usable via workbench".

I attached a screenshot of my proposal: integrating an on/off switch into Data Manager. This would activate direct manipulation for the currently selected node.

I guess for initial use this is sufficient. If there is more specialized need, I guess this would be driven by a specialized view that will want to controll gizmo interaction and configuration by itself. I do not imagine users configuring interaction in detail via the context menu (and neither via a specialized view that would _only_ configure the gizmo).

@Stefan, MITK team: are you ok with this menu entry? Can I integrate it like this? (please tell me if you prefer the module or core solution)

gizmo-datamanager.png (989×1 px, 239 KB)

Yesterday we only had a very short two man meeting but both of us wouldn't prefer to allow for manipulating multiple objects in parallel. We also have a fundamental question: Even in your example the center of the Gizmo is not visible and therefore how is it possible to drag the object? - Now imagine a cube, wouldn't it hide everything of the Gizmo? :)

(In reply to Stefan Kislinskiy from comment #9)

Yesterday we only had a very short two man meeting but both of us wouldn't
prefer to allow for manipulating multiple objects in parallel.

We could probably simply make this an option.

We also have
a fundamental question: Even in your example the center of the Gizmo is not
visible and therefore how is it possible to drag the object? - Now imagine a
cube, wouldn't it hide everything of the Gizmo? :)

First: this is a little problem with opaque objects. You still can click and drag the center (when guessing where it is) because picking is done exclusively on the gizmo object.

Second: the size of the gizmo is currently the longest of the three axes of an object. We could simply make it a multiple of that (say 20% extra) and thus have always at least some important parts of the gizmo visible.

Just an idea that came into my mind: When toggling the Gizmo for an object through the context menu, you could set the opacity of the object to 0.3 or 0.5, if it is opaque. However, some kind of state would be needed here in order to properly switch back without changing the opacity of already transparent objects.

How does the Gizmo behaves in presence of other interactors?

(In reply to Stefan Kislinskiy from comment #11)

Just an idea that came into my mind: When toggling the Gizmo for an object
through the context menu, you could set the opacity of the object to 0.3 or
0.5, if it is opaque.

Very good idea, I'll look into that.

How does the Gizmo behaves in presence of other interactors?

Hmm? As any other interactor they will compete for events. Do you have a specific example or worry?

In the 3D case your question is interesting, because there the logic is: if any of our MITK interactors (i.e. Gizmo) processes an events, event processing stops here. Otherwise, the event will be handed to the VTK camera interactor. Consequently camera and object interaction can coexist.

We finally discussed the Gizmo today with some colleagues and we concluded, that we still like the Gizmo (yay!) but that the context menu might be an inappropriate place as it is more like a (for medical staff dangerous) developer feature.

As long as it works fine (transparent objects to see the Gizmo, fast mappers, and hopefully undo/redo (? :-) ), we would start for example a bug squashing project for implementing a small plugin which is using the Gizmo.

(In reply to Stefan Kislinskiy from comment #13)

We finally discussed the Gizmo today with some colleagues and we concluded,
that we still like the Gizmo (yay!) but that the context menu might be an
inappropriate place as it is more like a (for medical staff dangerous)
developer feature.

As long as it works fine (transparent objects to see the Gizmo, fast
mappers, and hopefully undo/redo (? :-) ), we would start for example a bug
squashing project for implementing a small plugin which is using the Gizmo.

Ok, nice news. I'll see that I implement the transparency. Undo/Redo already works fine. Mapping speed seems ok for me, but needs to be seen with users.

So what is the future of this branch?

  1. I integrate it after transparency and removal of the menu entry? Then you'll add view functionality in some bug squashing project.
  2. I leave it a branch and you'll care for integration in a bug squashing project?

Yes and yes, it is okay for you?

(In reply to Stefan Kislinskiy from comment #15)

Yes and yes, it is okay for you?

Understanding by mail that I could choose the integration, I'll propose this third version:

I changed opacity handling and restricted the context menu to surfaces for the time being. A bugsquashing project can change this GUI aspect. Ok to integrate like this?

If you would like to integrate the Gizmo, than we would prefer a version without the GUI stuff, since we will remove it anyways from the context menu and we don't want external users to miss it after the next release. :-)

(In reply to Stefan Kislinskiy from comment #17)

If you would like to integrate the Gizmo, than we would prefer a version
without the GUI stuff, since we will remove it anyways from the context menu
and we don't want external users to miss it after the next release. :-)

You are right. The branch is modified accordingly. I'd still need a core modification flag to integrate a minor documentation improvement to a core class (ScaleOperation)

[474d84]: Merge branch 'bug-19489-3d-direct-geometry-manipulation-gizmo'

Merged commits:

2016-02-03 16:02:31 Daniel Maleike [b988cb]
Fixes from compiling with gcc


2016-02-03 15:29:14 Daniel Maleike [dc6a13]
Undo all GUI changes


2016-02-03 15:24:00 Daniel Maleike [30150a]
Remove gizmo menu from data manager


2016-02-03 11:16:02 Daniel Maleike [2e9ea7]
Restrict manipulation to surfaces


2016-02-03 09:45:10 Daniel Maleike [1fc5b2]
Reduce opacity of manipulated object


2016-01-13 18:36:09 Daniel Maleike [cf3f4c]
Add context menu action to data manager to toggle direct interaction

And remove last traces of direct manipulation from geometry tools


2016-01-13 14:56:37 Daniel Maleike [4961c3]
Rename GizmoInteractor3D to GizmoInteractor


2016-01-13 11:58:43 Daniel Maleike [2bd465]
Moving property initialization to mapper, documenting new mapper.


2016-01-12 19:16:42 Daniel Maleike [39513c]
Merge branch 'bug-19490-slicedgeometry-executeoperation' into bug-19489-3d-direct-geometry-manipulation-gizmo


2016-01-12 18:27:44 Daniel Maleike [2a2b10]
Add a 2D mapper for the gizmo, adapt interaction and touch everything


2016-01-11 18:29:10 Daniel Maleike [d2940f]
Fix gcc warnings


2016-01-11 16:59:28 Daniel Maleike [40db1c]
Add an object factory and rudimentary 2D mapper


2016-01-11 16:46:49 Daniel Maleike [524fbd]
Allow configuration (on/off) of translation/rotation/scaling, adapt visualization


2016-01-11 16:17:54 Daniel Maleike [0945d4]
Make undo/redo working


2016-01-11 12:28:41 Daniel Maleike [759d98]
Attempt undo/redo


2016-01-11 12:27:50 Daniel Maleike [9c2340]
Unfollow on destruction


2016-01-11 11:32:21 Daniel Maleike [c0f394]
Remove useless module activator


2016-01-11 10:36:51 Daniel Maleike [896669]
Fix picking (use cell picker), improve appearance


2016-01-08 18:12:35 Daniel Maleike [5d393f]
Implement scaling


2016-01-08 18:09:18 Daniel Maleike [29b99b]
DOC: be clearer on the documentation of the scale factor


2016-01-08 17:20:07 Daniel Maleike [a3b66d]
Fix: unregister observing when following a new geometry


2016-01-08 16:40:10 Daniel Maleike [9f1202]
Adopt colors of QmitkStdMultiWidget


2016-01-08 16:04:39 Daniel Maleike [50c811]
Fix rotations, improve visualization, document


2016-01-07 18:47:26 Daniel Maleike [7ae3bb]
First go at rotations


2016-01-07 16:59:55 Daniel Maleike [2a0051]
Complete state machine and implement gizmo translations (along axis and free)


2016-01-05 19:29:25 Daniel Maleike [2fbcc1]
Start interactor: picking and detection of corresponding gizmo part


2016-01-11 11:40:48 Daniel Maleike [364802]
Merge branch 'bug-19487-vtk-picking-broken' into bug-19489-3d-direct-geometry-manipulation-gizmo


2016-01-11 11:40:36 Daniel Maleike [92de0b]
Merge branch 'bug-19486-events-filtering-broken-for-specific-renderers' into bug-19489-3d-direct-geometry-manipulation-gizmo


2016-01-05 10:46:03 Daniel Maleike [0bd36a]
Initial 3D "gizmo", adapting to followed object's geometry

To anybody who will implement GUI functionality: code that attached/removes the gizmo a a DataNode has been removed here:

http://mitk.org/git/?p=MITK.git;a=commit;h=30150a719ada1c89c7325320c183d06ec01c2dd8

[4a2ef8]: Merge branch 'bug-19489-3d-direct-geometry-manipulation-gizmo'

Merged commits:

2016-02-03 17:03:19 Daniel Maleike [42fd1e]
COMP: guessing what could be bad for VS2012Express