Custom Manipulators: General Design & Functionality #47345

New Issue

Julian Eisel · 2016-02-06T16:03:35+01:00

Julian Eisel commented

2016-02-06 16:03:35 +01:00

There are a number of features that should be supported but further design work is needed before they can be implemented properly. Everyone is welcome to join the discussion by proposing more ideas or solutions, by creating mockups or by just giving some own input.

Scope of Widgets

Description

When should a tool use a widget?

Examples:

Edit Mesh Spin Tool
Edit Mesh Smooth tool (number of steps, smooth factor)
Edit Mesh Bevel/Inset
Edit Mesh UV Rotate
Edit Mesh Subdivide

Spin tool is an example where widgets make a lot of sense (you rotate around an axis, so direct manipulation is useful).

The issue with Smooth & UV-Rotate is that using a 3D manipulator for these is using manipulator simply as a way to access buttons in the view-port.

An issue with bevel/inset depends on the kind of manipulator used. Having a single manipulator in the view doesn't directly relate to the edge, and again - its more a replacement for accessing buttons in the tool-bar.

Proposed Solutions

Suggest not to use manipulators if they are simply an alternate access to buttons.

As for bevel/inset: we could make the bevel edges themselves into manipulators, so you could click on beveled edge and drag it.

Toggling Visibility of Widgets

Description

Currently, only the widgets of the active object are drawn. While this works for most cases, being able to precisely control which widgets are visible and which not can be useful.
For example, in future, a camera could have widgets for the focal length, sensor size, depth of field distance, ... If all are visible all the time it's easy to accidentally manipulate them.

Proposed Solutions

Draw a panel for the active object in which its widgets can be enabled/disabled individually (similar to "Display" for cameras).
Add a toggle button next to every button represented by a widget (similar to how it's done in the transform panel in the properties region, where you can press the 'lock' icon to disable the widget for this axis)

Open Topics

Where would the manipulator toggles be stored? (Object / Viewport / Tool-Settings)
How to expose settings that aren't related directly to objects? (Group Center, View-Port Clipping Bounds)

Numerical Input

Description

It should be possible for users to input precise values to manipulate a widget (and thus the value it represents). This way they can keep their locus of attention in the viewport, avoiding having to search for a button in the UI.

Proposed Solutions

Enabling number input by holding a modifier key while clicking on widget (as in - Ctrl+LMB on widget activates modal mode to input value)

Snap System

Users may want to snap manipulators to other elements in the scene, eg:

Snapping the spin center-point to a vertex on a mesh.
Snapping bisect angle to a vertex
Snapping the camera's DOF to the surface of an object.

Note that currently holding Ctrl sets WM_MANIPULATOR_TWEAK_SNAP but each manipulator needs to implement this.

Proposed Solutions

Each manipulator has a snap flag for 'TRANSLATE | ROTATE | SCALE', when set, holding Ctrl will snap to any of the elements set.
Snapping can also respect scene settings (in the 3D) view-port, so users can snap as with mesh edit-mode.

Key Framing

When the cursor is over a manipulator, do we want to support I-Key to keyframe that setting (DOF, lense for eg).

Theme Colors

Manipulators now use theme colors, there are basic preset colors to use: (HIGHLIGHT, PRIMARY, SECONDARY, A, B).

Where A/B are for other controls.

Currently they're hard coded in manipulators but they can be set however we like.

There are a number of features that should be supported but further design work is needed before they can be implemented properly. Everyone is welcome to join the discussion by proposing more ideas or solutions, by creating mockups or by just giving some own input. ---- # Scope of Widgets ### Description When should a tool use a widget? Examples: * Edit Mesh Spin Tool * Edit Mesh Smooth tool (number of steps, smooth factor) * Edit Mesh Bevel/Inset * Edit Mesh UV Rotate * Edit Mesh Subdivide Spin tool is an example where widgets make a lot of sense (you rotate around an axis, so direct manipulation is useful). The issue with Smooth & UV-Rotate is that using a 3D manipulator for these is using manipulator simply as a way to access buttons in the view-port. An issue with bevel/inset depends on the kind of manipulator used. Having a single manipulator in the view doesn't directly relate to the edge, and again - its more a replacement for accessing buttons in the tool-bar. ### Proposed Solutions Suggest not to use manipulators if they are simply an alternate access to buttons. As for bevel/inset: we could make the bevel edges themselves into manipulators, so you could click on beveled edge and drag it. ---- # Toggling Visibility of Widgets ### Description Currently, only the widgets of the active object are drawn. While this works for most cases, being able to precisely control which widgets are visible and which not can be useful. For example, in future, a camera could have widgets for the focal length, sensor size, depth of field distance, ... If all are visible all the time it's easy to accidentally manipulate them. ### Proposed Solutions * Draw a panel for the active object in which its widgets can be enabled/disabled individually (similar to "Display" for cameras). * Add a toggle button next to every button represented by a widget (similar to how it's done in the transform panel in the properties region, where you can press the 'lock' icon to disable the widget for this axis) ### Open Topics * Where would the manipulator toggles be stored? (Object / Viewport / Tool-Settings) * How to expose settings that aren't related directly to objects? (Group Center, View-Port Clipping Bounds) ---- # Numerical Input ### Description It should be possible for users to input precise values to manipulate a widget (and thus the value it represents). This way they can keep their locus of attention in the viewport, avoiding having to search for a button in the UI. ### Proposed Solutions * Enabling number input by holding a modifier key while clicking on widget (as in - Ctrl+LMB on widget activates modal mode to input value) --- # Snap System Users may want to snap manipulators to other elements in the scene, eg: * Snapping the spin center-point to a vertex on a mesh. * Snapping bisect angle to a vertex * Snapping the camera's DOF to the surface of an object. Note that currently holding Ctrl sets `WM_MANIPULATOR_TWEAK_SNAP` but each manipulator needs to implement this. ### Proposed Solutions * Each manipulator has a snap flag for 'TRANSLATE | ROTATE | SCALE', when set, holding Ctrl will snap to any of the elements set. * Snapping can also respect scene settings (in the 3D) view-port, so users can snap as with mesh edit-mode. ---- # Key Framing When the cursor is over a manipulator, do we want to support I-Key to keyframe that setting (DOF, lense for eg). ---- # Theme Colors Manipulators now use theme colors, there are basic preset colors to use: (HIGHLIGHT, PRIMARY, SECONDARY, A, B). Where A/B are for other controls. *Currently they're hard coded in manipulators but they can be set however we like.*

Julian Eisel commented

2016-02-06 16:03:35 +01:00

Changed status to: 'Open'

Julian Eisel commented

2016-02-06 16:03:35 +01:00

Added subscriber: @JulianEisel

Aaron Carlisle commented

2016-02-06 16:13:10 +01:00

Added subscriber: @Blendify

mathieu menuet commented

2016-02-06 18:32:59 +01:00

Added subscriber: @bliblubli

mathieu menuet commented

2016-02-06 18:40:48 +01:00

For numerical input, would it be possible to just have the normal mouse input until a number is pressed. If a number is pressed, then it has the priority and hitting tab allows to switch between the different parameters (like for example the x, y and z coordinates).
It would have following benefits:

user will not need a manual to find it
it would leave more free space to the keymap.
it would allow to further use ctrl for snapping, alt for mutli-object editing and shift for slow increment.

For numerical input, would it be possible to just have the normal mouse input until a number is pressed. If a number is pressed, then it has the priority and hitting tab allows to switch between the different parameters (like for example the x, y and z coordinates). It would have following benefits: - user will not need a manual to find it - it would leave more free space to the keymap. - it would allow to further use ctrl for snapping, alt for mutli-object editing and shift for slow increment.

blend-it commented

2016-02-07 11:00:02 +01:00

Added subscriber: @blend-it

Diego Gangl commented

2016-02-07 22:21:39 +01:00

Added subscriber: @Januz

Cenek Strichel commented

2016-02-24 22:47:37 +01:00

Added subscriber: @Cenda

Campbell Barton commented

2016-02-25 23:14:02 +01:00

Added subscriber: @ideasman42

Jonathan Williamson commented

2016-02-29 00:16:38 +01:00

Added subscriber: @JonathanWilliamson

Jonathan Williamson commented

2016-02-29 00:16:38 +01:00

== Toggling Visibility of Widgets
Proposed Solutions
Draw a panel for the active object in which its widgets can be enabled/disabled individually (similar to "Display" for cameras).
Add a toggle button next to every button represented by a widget (similar to how it's done in the transform panel in the properties region, where you can press the 'lock' icon to disable the widget for this axis)

Initially I liked the panel option more, but the issue with this is that the options for the widgets would no longer be directly (both visually and contextually) associated with their corresponding values. For this reason I think the toggle button, similar to the Snap Widget. I do worry about UI bloat with this, though, which could become quite prevalent if there are many widgets.

== Numerical Input
Description
It should be possible for users to input precise values to manipulate a widget (and thus the value it represents). This way they can keep their locus of attention in the viewport, avoiding having to search for a button in the UI.

Proposed Solutions
Enabling number input by holding a modifier key while clicking on widget (as in - Ctrl+LMB on widget activates modal mode to input value)

As for numerical input, I feel this is a bit unnecessary (at least initially). One of the many benefits of a widget workflow is specifically to get away from more specific, numerical inputs and instead let the artist work visually directly on the tool. That's not to say that numerical input options are bad, or to be avoided, but I certainly wouldn't put a priority on it.

>== Toggling Visibility of Widgets >**Proposed Solutions** >Draw a panel for the active object in which its widgets can be enabled/disabled individually (similar to "Display" for cameras). >Add a toggle button next to every button represented by a widget (similar to how it's done in the transform panel in the properties region, where you can press the 'lock' icon to disable the widget for this axis) Initially I liked the panel option more, but the issue with this is that the options for the widgets would no longer be directly (both visually and contextually) associated with their corresponding values. For this reason I think the toggle button, similar to the Snap Widget. I do worry about UI bloat with this, though, which could become quite prevalent if there are many widgets. >== Numerical Input >**Description** >It should be possible for users to input precise values to manipulate a widget (and thus the value it represents). This way they can keep their locus of attention in the viewport, avoiding having to search for a button in the UI. > >**Proposed Solutions** >Enabling number input by holding a modifier key while clicking on widget (as in - Ctrl+LMB on widget activates modal mode to input value) As for numerical input, I feel this is a bit unnecessary (at least initially). One of the many benefits of a widget workflow is specifically to get away from more specific, numerical inputs and instead let the artist work visually directly on the tool. That's not to say that numerical input options are bad, or to be avoided, but I certainly wouldn't put a priority on it.

Diego Gangl commented

2016-03-05 00:32:41 +01:00

Another possible solution: more widgets!

(I made up the focal length one)

There could be a modal op that allows to configure widgets. In this op widgets would get a small label besides them with an eye icon. Disable widgets show up semi-transparent. Clicking on the label toggles them.

This op could be called from a menu and/or a button in the N-panel. There could be another button to save visibility settings as the default for that object type.

In the future, if widgets become complex enough to have their own options the labels could hold an extra button to bring up a settings menu.

Another possible solution: more widgets! ![moar_widgets.png](https://archive.blender.org/developer/F287679/moar_widgets.png) (I made up the focal length one) There could be a modal op that allows to configure widgets. In this op widgets would get a small label besides them with an eye icon. Disable widgets show up semi-transparent. Clicking on the label toggles them. This op could be called from a menu and/or a button in the N-panel. There could be another button to save visibility settings as the default for that object type. In the future, if widgets become complex enough to have their own options the labels could hold an extra button to bring up a settings menu.

Paweł Łyczkowski commented

2016-03-09 19:43:15 +01:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2016-03-09 19:43:15 +01:00

Currently, only the widgets of the active object are drawn. While this works for most cases, being able to precisely control which widgets are visible and which not can be useful.

I would say - draw Extended Properties (name I just came up with) widgets for all selected objects. control their visibility globally just like the Transform widget is controlled. Add a Extended Properties widget visibility button next to the existing Transform widget visibility button.

It should be possible for users to input precise values to manipulate a widget (and thus the value it represents).

Won't the widget be always linked to a numerical value in the Properties Editor? Like Camera's focal length, or a custom rig property?

>Currently, only the widgets of the active object are drawn. While this works for most cases, being able to precisely control which widgets are visible and which not can be useful. I would say - draw Extended Properties (name I just came up with) widgets for all selected objects. control their visibility globally just like the Transform widget is controlled. Add a Extended Properties widget visibility button next to the existing Transform widget visibility button. >It should be possible for users to input precise values to manipulate a widget (and thus the value it represents). Won't the widget be always linked to a numerical value in the Properties Editor? Like Camera's focal length, or a custom rig property?

voyager25 commented

2016-03-09 20:38:54 +01:00

Added subscriber: @voyager25

Duarte Farrajota Ramos commented

2016-10-05 04:32:34 +02:00

Added subscriber: @DuarteRamos

michael knubben commented

2017-03-24 09:45:49 +01:00

Added subscriber: @michaelknubben

Duarte Farrajota Ramos commented

2017-06-19 02:58:46 +02:00

Better snapping system is a very important and necessary for a lot of people doing more kind of "precision" or "hard edge" modelling work.
The proposal at #45734 (Grab, rotate, scale with basepoint) holds some really promising results that I would love eventually see implemented, one way or another.

Widgets, in general would ideally behave sort of like an Empty object in the viewport, allowing the user to move and snap them to any type of existing geometry, just like an empty would, prior to initiating the operation.
This would not only effectively set the spinning/rotation pivot point, but also ideally allow specifying a "base point" used has snap target while transforming.

The linked patch shows a really good workflow of how this could actually work, comments there suggested it was hard to find, though I did like it a lot

Better snapping system is a very important and necessary for a lot of people doing more kind of "precision" or "hard edge" modelling work. The proposal at #45734 (Grab, rotate, scale with basepoint) holds some really promising results that I would love eventually see implemented, one way or another. Widgets, in general would ideally behave sort of like an *Empty* object in the viewport, allowing the user to move and snap them to any type of existing geometry, just like an empty would, prior to initiating the operation. This would not only effectively set the spinning/rotation pivot point, but also ideally allow specifying a "base point" used has snap target while transforming. The linked patch shows a really good workflow of how this could actually work, comments there suggested it was hard to find, though I did like it a lot ![2015 08 26 comments.png](https://archive.blender.org/developer/F228098/2015_08_26_comments.png)

Campbell Barton commented

2017-06-19 04:55:02 +02:00

Re: Toggling Visibility of Widgets

I think this might be best made into a scene-toolsettings option exposed in a menu or panel. (Was thinking it could be a view-port setting but can imagine it could be annoying to set these multiple times in each viewport if you're switching between some different views/windows, although my opinion isn't really strong one way or the other).

So for eg a panel in the 3D view could have toggle for:

View-port [Render Border, Clipping Border, Background Image]
Object: [Dupli-Group Center, Empty Image Placement]
Camera [Shift, DOF, Lens]
Lamp [Energy, Area Size, Spot Size, Spot blend]
Bone [Roll, Envelope]

Exact items displayed could depends on mode and active object (to avoid too much UI clutter).

Re: **Toggling Visibility of Widgets** I think this might be best made into a scene-toolsettings option exposed in a menu or panel. *(Was thinking it could be a view-port setting but can imagine it could be annoying to set these multiple times in each viewport if you're switching between some different views/windows, although my opinion isn't really strong one way or the other)*. So for eg a panel in the 3D view could have toggle for: * View-port [Render Border, Clipping Border, Background Image] * Object: [Dupli-Group Center, Empty Image Placement] * Camera [Shift, DOF, Lens] * Lamp [Energy, Area Size, Spot Size, Spot blend] * Bone [Roll, Envelope] ---- Exact items displayed could depends on mode and active object (to avoid too much UI clutter).

Campbell Barton changed title from ~~Custom Manipulators: General (Advanced) Functionality~~ to Custom Manipulators: General Design & Functionality

2017-06-21 03:04:06 +02:00

Florian Meyer commented

2017-08-10 16:46:03 +02:00

Added subscriber: @florianfelix

Florian Meyer commented

2017-08-10 16:46:03 +02:00

Tool-Tips

I think it may be beneficial if manipulator widgets had the ability to display some kind of tool-tip.
When there are many visually nondescript arrow widgets on screen it can become rather confusing as to what they actually do.
Having Tool-tips (always or maybe only when hovering over them) would imo drastically reduce the
time to get comfortable with what may become a multitude of official and community supplied manipulators.

Tool-Tips I think it may be beneficial if manipulator widgets had the ability to display some kind of tool-tip. When there are many visually nondescript arrow widgets on screen it can become rather confusing as to what they actually do. Having Tool-tips (always or maybe only when hovering over them) would imo drastically reduce the time to get comfortable with what may become a multitude of official and community supplied manipulators. ![manipulator_tooltips.jpg](https://archive.blender.org/developer/F704629/manipulator_tooltips.jpg)

Dolf Veenvliet commented

2017-12-30 08:57:23 +01:00

Added subscriber: @macouno-3

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Custom Manipulators: General Design & Functionality #47345

Scope of Widgets

Description

Proposed Solutions

Toggling Visibility of Widgets

Description

Proposed Solutions

Open Topics

Numerical Input

Description

Proposed Solutions

Snap System

Proposed Solutions

Key Framing

Theme Colors