Custom Manipulators: General Design & Functionality
Open, NormalPublic

Description

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.

Details

Type
Design
Julian Eisel (Severin) updated the task description. (Show Details)
Julian Eisel (Severin) raised the priority of this task from to Normal.
Julian Eisel (Severin) set Type to Design.

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.

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.

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.

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?

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 T45734: 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

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 (campbellbarton) renamed this task from Custom Manipulators: General (Advanced) Functionality to Custom Manipulators: General Design & Functionality.Jun 21 2017, 3:04 AM

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.