Custom Manipulators: Where to take advantage of manipulators #51844

Open
opened 2017-06-19 03:12:44 +02:00 by Campbell Barton · 60 comments

This task is to collect a list of properties & tools that can take advantage of custom manipulators.

Feel free to post suggestions as comments so we can review them to include in this list, or suggest reasons why any of the suggestions should be rejected.


Note that this task is not intended to go into highly detailed design for each kind of manipulator, for this we can link to a separate design tasks if its needed.
Some rough description of design may be useful here just to communicate whats intended.

Persistent Transform Manipulators

Image Editor: UV Manipulator

Similar to 3D view, a manipulator for transforming UV's.

F-Curve: Key-Frame Manipulator

Similar to 3D view, a manipulator for transforming bezier curve handles. (could use some design & discussion with animations)


Properties


3D View: Paint Mask Image

The mask image used for painting could use a manipulator to place it.


3D View: Camera DOF distance (done)

DOF distance manipulator can be edited when "Limits" are enabled.


3D View: Camera/Lamp Focal-Length/Spot-Size (done)

Support using the spot axis or camera frame to adjust the angle of the spot / focal length.


3D View: Force Field (done)

Support using an arrow to adjust wind strength.


3D View: Clipping Border

Currently the only way to set the view-port clipping is with drawing a border in the view, there is no way to adjust it afterwards.

Benefit: If the initial border isn't accurate or the user wants to adjust it, they can adjust the box instead of re-drawing it each time.

Design Summary: Each plane of the clipping border can be rotated or translated on its axis (not sure exactly how this should work, some design is needed).

Open Topics:

  • We might want the ability to adjust this at any time. How to do this in a way that isn't too distracting, or how to set the manipulator as active?

3D View: Area Lamp Size (done b569151ffb)

The rectangle defined by the area lamp could be adjusted by clicking on it.

Benefit: Simply allows direct editing of this setting in the viewport.

Design Summary: The area rectangle would be a hotspot that can be clicked on to adjust.

Open Topics:

  • Would we want a way to change between square and rectangle on-screen too?

3D View: Camera/Lamp Target (done 459365443f) demo video

This would be a kind of transformation manipulator where you can point the lamp or camera onto the surface of an object to control what the camera looks at (like having a temporary track-to constraint).

Benefit: Users could easily point cameras & spot lamps to a location without having to preview render or set it as the active camera.

Design Summary: This would likely be handle on the camera/lamps view axis.


3D View: Camera Shift

Benefit: Currently adjusting shift buttons is quite indirect, this could be supported a little like panning the camera view.

Design Summary: Suggest this be a small grab widget in the camera corner, only visible from within the camera view. (This could also have a key-binding associated with it)


3D View: Empty Image (done 5406109fbf)

Benefit: This is positioned in 3D space but currently only editable via buttons.

Design Summary: Would use a rectangle cage (corners and center-point) to edit the placement of the image empty.


3D View: 3D Text-Box

Benefit: This is positioned in 3D space but currently only editable via buttons.

Design Summary: Would use a rectangle cage (same as empty image).


3D View: Edit Mode, Bone Roll

This may be an addition to the existing transform-manipulator.

Benefit: Simply gives a more direct way of adjusting the bone roll, it could support snapping too, in a way the button value doesn't - snap to axis or parent axis for eg.

Design Summary: An outer ring could be used to adjust the bone roll in edit-mode.


3D View: Pose Mode, B-Bone Roll

B-Bones have head and tail roll angles, currently only editable via buttons.


3D View: Pose Mode, B-Bone Spline (done d3ba86de07)

B-Bones define splines, currently only editable via buttons.


3D View: Curve Vertex Attributes

Allow editing of BezierSplinePoint.radius & tilt.

Benefit: Radius and especially tilt are a little abstract when editing via buttons, direct manipulator access makes it clear what you're editing.

Design Summary: The active vertex would have a radius and tilt widget around it (possibly larger then the transform manipulators so they can co-exist).

Open Topics:

  • Would this edit only the active vertex or all vertices?

Nodes (Compositor): Box/Ellipse Mask

It should be possible to change size and position of the Box/Ellipse Mask borders per widget.


~~Nodes (Compositor): Viewer Node ~~ (done)

The tile ordering center (which already looks like a widget) should be a draggable widget too.


Nodes (Compositor): Viewer Border (CTRL+B) (done fe8fcb4343)

Adjust the border bounds


Nodes (Compositor): Translate / Transform / Scale / Crop Nodes (done d7905dab6a)

It should be possible to perform all transforms through a widget, like in any other image editing program.


Nodes (Compositor): Sun Beams (done 3f644682b0)

There is a position input for the sub beams node, which could be widgetified as well.


Nodes (Compositor): Corner Pin node (done ba4ffe90cd)

This node desperately needs a widget. Pretty simple widget, just four corners. I suppose it could also have the soon-to-be-standard transform widget in the center of it, as well (that would be a nice bonus!)


Movie Clip Editor: Track Transform

Transform manipulator for aspect ratio, width and height and rotating.


Movie Clip Editor: Transform (Cage)

It would be great to have a box widget that appeared when ever more than one control point was selected. This widget would let you move, rotate, scale, and warp the selected control point positions.

Also, there should be a hotkey to turn on/off widget visibility, at least in the compositor. This is necessary to get a clear, unobstructed view of the composited image.


Tools


3D View: Edit Mesh Spin (done)

Modify the center axis, and angle.


3D View: Edit Mesh Screw

Modify the center axis, and turns.


3D View: Edit Mesh Edge Slide

While interactive edge slide doesn't especially require a manipulator, adjusting settings after using a number button is quite indirect.

Benefit: This allows tweaking edge slide input without using operator redo panel, though admittedly this isn't the most important use-case for manipulators.

Design Summary: The closest edge-rail to the cursor would be used as a manipulator (Internally Blender is already defining an edge-rail for this tool, so its only a matter of highlighting it).

Modifiers / Constraints

Note that its an open-topic if we even should support manipulators for modifiers, so making a short-list of possible uses here to see if its worth supporting.

Modifiers:

  • Array Modifier (center, rotation).
  • Screw Modifier (axis, angle, offset).
  • Wave (center, falloff, width)
  • Simple deform (center, limits, angle)
  • Mirror (symmetry plane)
  • Cast (center)
  • Hook (center, radius, strength)

Constraints:

  • Pivot (center)
  • Rigit Body Joint (center, rotation)

Undecided Suggestions

Putting items here which may requite more design before we can tell if they are something that fit well as manipulators.

  • 3D View: Group offset Group.dupli_offset currently only adjustable manually through coordinate input or from 3D cursor position

    Reason: It's not clear what this setting would be attached to, when would you see this manipulator in the 3D view and how would you know which group you were editing. Also, since this often is left at zero, its likely any object with a group would show some manipulator at the view center. I think this might need its own design task - or have a general design task where we figure out how to expose arbitrary location settings as manipulators in a way that isn't annoying/distracting.

If this is added, I think it would need to be off by default, noted here: T47345#441258 ~ ideasman42
  • 3D View: Proportional Editing, Vector would be a moved arrow for translation and scaling. There would be a circle for proportional size. And between both an horizontal line could be modified used as a curve widget to adjust falloff.

    Reason: I worry this conflicts with existing transform manipulator. ~ ideasman42

  • 3D View: Move Object Origin

    Reason: Object origin isn't a property, the manipulator would be moving all object data. This is another example of a manipulator that you would probably want to keep disabled, the effort to enable, access & disable seems like it might not be worth the hassle, although I can see this point is disputable too. ~ ideasman42


Postponed Suggestions

This is simply to list some ideas that may be useful but out-of-scope for this task, or too controversial (where there is too much design needed or questionable if they should even be manipulators).

  • 3D View: If possible a "move-like" widget to manually place/snap the 3D cursor about the scene SpaceView3D.cursor_location

    Reason: I think making the 3D cursor into its own widget would conflict with placing it, OTOH something like this functionality could be useful, so think this is more of a design task (see: blender/blender-addons#28451 #40952). ~ ideasman42.

  • 3D View: Bezier curve extrusion value Curve.extrude, bonus points if it allowed snapping with the hypothetical widget snapping system

    Reason: There are quite a few bevel settings for curves and text its not clear which you would show in the 3D view and I suspect if you are editing some of these settings you probably want to edit others. Another reason am unsure of this is there isn't an obvious place to show the manipulator. ~ ideasman42

  • 3D View: Texture Mapping, For a mapping node taking as an entry generated or world coordinates (an origin that correspond to point easy to identify in 3DView) , we can think of a manipulator in 3D view to set offset, scale or rotation of the coordinates. There could be a manipulator visible only in camera view for Window or Camera coordinates.

    Reason: Blender's texturing pipeline is likely to move to using nodes, this means we will likely end up needing a way to display a manipulator for a node in the 3D-View. Thats fine but not a straightforward task.

  • 3D View: Rotate Edge or UVs or Colors. When dealing with Ngons, we can need to do several iteration of Rotate Edges. And for rotating UVs and colors, we have another operator to Reverse UVs and Reverse Colors. An interactive manipulator could decrease number of calls and number of operators.

    Reason: Nothing wrong with this suggestion but it seems a bit obscure. Also we would need to add the option to set the number of steps for this tool.

This task is to collect a list of properties & tools that can take advantage of custom manipulators. Feel free to post suggestions as comments so we can review them to include in this list, or suggest reasons why any of the suggestions should be rejected. ---- Note that this task is not intended to go into highly detailed design for each kind of manipulator, for this we can link to a separate design tasks if its needed. Some rough description of design may be useful here just to communicate whats intended. # Persistent Transform Manipulators **Image Editor: UV Manipulator** Similar to 3D view, a manipulator for transforming UV's. **F-Curve: Key-Frame Manipulator** Similar to 3D view, a manipulator for transforming bezier curve handles. *(could use some design & discussion with animations)* ---- # Properties ---- **3D View: Paint Mask Image** The mask image used for painting could use a manipulator to place it. ---- **~~3D View: Camera DOF distance~~ (done)** DOF distance manipulator can be edited when "Limits" are enabled. ---- **~~3D View: Camera/Lamp Focal-Length/Spot-Size~~ (done)** Support using the spot axis or camera frame to adjust the angle of the spot / focal length. ---- **~~3D View: Force Field~~ (done)** Support using an arrow to adjust wind strength. ---- **3D View: Clipping Border** Currently the only way to set the [view-port clipping ](https://docs.blender.org/manual/en/dev/editors/3dview/navigate/clip.html) is with drawing a border in the view, there is no way to adjust it afterwards. **Benefit:** If the initial border isn't accurate or the user wants to adjust it, they can adjust the box instead of re-drawing it each time. **Design Summary:** Each plane of the clipping border can be rotated or translated on its axis (not sure *exactly* how this should work, some design is needed). **Open Topics:** * We might want the ability to adjust this at any time. How to do this in a way that isn't too distracting, or how to set the manipulator as active? ---- **~~3D View: Area Lamp Size~~ (done b569151ffb)** The rectangle defined by the area lamp could be adjusted by clicking on it. **Benefit:** Simply allows direct editing of this setting in the viewport. **Design Summary:** The area rectangle would be a hotspot that can be clicked on to adjust. **Open Topics:** * Would we want a way to change between square and rectangle on-screen too? ---- **~~3D View: Camera/Lamp Target~~ (done 459365443f) [demo video ](https://www.youtube.com/watch?v=xXzpQitJAhE)** This would be a kind of transformation manipulator where you can point the lamp or camera onto the surface of an object to control what the camera looks at *(like having a temporary track-to constraint)*. **Benefit:** Users could easily point cameras & spot lamps to a location without having to preview render or set it as the active camera. **Design Summary:** This would likely be handle on the camera/lamps view axis. ---- **3D View: Camera Shift** **Benefit:** Currently adjusting shift buttons is quite indirect, this could be supported a little like *panning* the camera view. **Design Summary:** Suggest this be a small *grab* widget in the camera corner, only visible from within the camera view. *(This could also have a key-binding associated with it)* ---- **~~3D View: Empty Image~~ (done 5406109fbf)** **Benefit:** This is positioned in 3D space but currently only editable via buttons. **Design Summary:** Would use a rectangle cage (corners and center-point) to edit the placement of the image empty. ---- **3D View: 3D Text-Box** **Benefit:** This is positioned in 3D space but currently only editable via buttons. **Design Summary:** Would use a rectangle cage (same as empty image). ---- **3D View: Edit Mode, Bone Roll** This may be an addition to the existing transform-manipulator. **Benefit:** Simply gives a more direct way of adjusting the bone roll, it could support snapping too, in a way the button value doesn't - snap to axis or parent axis for eg. **Design Summary:** An outer ring could be used to adjust the bone roll in edit-mode. ---- **3D View: Pose Mode, B-Bone Roll** B-Bones have head and tail roll angles, currently only editable via buttons. ---- **~~3D View: Pose Mode, B-Bone Spline~~ (done d3ba86de07)** B-Bones define splines, currently only editable via buttons. ---- **3D View: Curve Vertex Attributes** Allow editing of `BezierSplinePoint.radius` & `tilt`. **Benefit:** Radius and especially tilt are a little abstract when editing via buttons, direct manipulator access makes it clear what you're editing. **Design Summary:** The active vertex would have a radius and tilt widget around it (possibly larger then the transform manipulators so they can co-exist). **Open Topics:** * Would this edit only the active vertex or all vertices? ---- **Nodes (Compositor): Box/Ellipse Mask** It should be possible to change size and position of the Box/Ellipse Mask borders per widget. ---- **~~Nodes (Compositor): Viewer Node ~~ (done)** The tile ordering center (which already looks like a widget) should be a draggable widget too. ---- **~~Nodes (Compositor): Viewer Border~~ (CTRL+B) (done fe8fcb4343)** Adjust the border bounds ---- **Nodes (Compositor): Translate / Transform / Scale / ~~Crop~~ Nodes (done d7905dab6a)** It should be possible to perform all transforms through a widget, like in any other image editing program. ---- **~~Nodes (Compositor): Sun Beams~~ (done 3f644682b0)** There is a position input for the sub beams node, which could be widgetified as well. ---- **~~Nodes (Compositor): Corner Pin node~~ (done ba4ffe90cd)** This node desperately needs a widget. Pretty simple widget, just four corners. I suppose it could also have the soon-to-be-standard transform widget in the center of it, as well (that would be a nice bonus!) ---- **Movie Clip Editor: Track Transform** Transform manipulator for aspect ratio, width and height and rotating. ---- **Movie Clip Editor: Transform (Cage)** It would be great to have a box widget that appeared when ever more than one control point was selected. This widget would let you move, rotate, scale, and warp the selected control point positions. Also, there should be a hotkey to turn on/off widget visibility, at least in the compositor. This is necessary to get a clear, unobstructed view of the composited image. ---- # Tools ---- **3D View: ~~Edit Mesh Spin~~ (done)** Modify the center axis, and angle. ---- **3D View: Edit Mesh Screw** Modify the center axis, and turns. ---- **3D View: Edit Mesh Edge Slide** While interactive edge slide doesn't especially require a manipulator, adjusting settings after using a number button is quite indirect. **Benefit:** This allows tweaking edge slide input without using operator redo panel, though admittedly this isn't the most important use-case for manipulators. **Design Summary:** The closest edge-rail to the cursor would be used as a manipulator *(Internally Blender is already defining an edge-rail for this tool, so its only a matter of highlighting it)*. # Modifiers / Constraints Note that its an open-topic if we even should support manipulators for modifiers, so making a short-list of possible uses here to see if its worth supporting. **Modifiers:** * Array Modifier (center, rotation). * Screw Modifier (axis, angle, offset). * Wave (center, falloff, width) * Simple deform (center, limits, angle) * Mirror (symmetry plane) * Cast (center) * Hook (center, radius, strength) **Constraints:** * Pivot (center) * Rigit Body Joint (center, rotation) ---- # Undecided Suggestions Putting items here which may requite more design before we can tell if they are something that fit well as manipulators. * 3D View: Group offset `Group.dupli_offset` currently only adjustable manually through coordinate input or from 3D cursor position **Reason:** It's not clear what this setting would be attached to, when would you see this manipulator in the 3D view and how would you know which group you were editing. Also, since this often is left at zero, its likely any object with a group would show some manipulator at the view center. I think this might need its own design task - or have a general design task where we figure out how to expose arbitrary location settings as manipulators in a way that isn't annoying/distracting. ``` If this is added, I think it would need to be off by default, noted here: T47345#441258 ~ ideasman42 ``` * 3D View: Proportional Editing, Vector would be a moved arrow for translation and scaling. There would be a circle for proportional size. And between both an horizontal line could be modified used as a curve widget to adjust falloff. **Reason:** I worry this conflicts with existing transform manipulator. ~ ideasman42 * 3D View: Move Object Origin **Reason:** Object origin isn't a property, the manipulator would be moving all object data. This is another example of a manipulator that you would probably want to keep disabled, the effort to enable, access & disable seems like it might not be worth the hassle, although I can see this point is disputable too. ~ ideasman42 ---- # Postponed Suggestions This is simply to list some ideas that may be useful but out-of-scope for this task, or too controversial *(where there is too much design needed or questionable if they should even be manipulators)*. * 3D View: If possible a "move-like" widget to manually place/snap the 3D cursor about the scene `SpaceView3D.cursor_location` **Reason:** I think making the 3D cursor into its own widget would conflict with placing it, OTOH something like this functionality could be useful, so think this is more of a design task (see: blender/blender-addons#28451 #40952). ~ ideasman42. * 3D View: Bezier curve extrusion value `Curve.extrude`, bonus points if it allowed snapping with the hypothetical widget snapping system **Reason:** There are quite a few bevel settings for curves and text its not clear which you would show in the 3D view and I suspect if you are editing some of these settings you probably want to edit others. Another reason am unsure of this is there isn't an obvious place to show the manipulator. ~ ideasman42 * 3D View: Texture Mapping, For a mapping node taking as an entry generated or world coordinates (an origin that correspond to point easy to identify in 3DView) , we can think of a manipulator in 3D view to set offset, scale or rotation of the coordinates. There could be a manipulator visible only in camera view for Window or Camera coordinates. **Reason:** Blender's texturing pipeline is likely to move to using nodes, this means we will likely end up needing a way to display a manipulator for a node in the 3D-View. Thats fine but not a straightforward task. * 3D View: Rotate Edge or UVs or Colors. When dealing with Ngons, we can need to do several iteration of Rotate Edges. And for rotating UVs and colors, we have another operator to Reverse UVs and Reverse Colors. An interactive manipulator could decrease number of calls and number of operators. **Reason:** Nothing wrong with this suggestion but it seems a bit obscure. Also we would need to add the option to set the number of steps for this tool.
Author
Owner

Changed status to: 'Open'

Changed status to: 'Open'
Author
Owner

Added subscribers: @ideasman42, @JulianEisel

Added subscribers: @ideasman42, @JulianEisel

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos
Campbell Barton changed title from Custom Manipulators: Identify areas where they can be used to Custom Manipulators: Identify areas we can take advantage of manipulators 2017-06-19 03:40:27 +02:00
Campbell Barton changed title from Custom Manipulators: Identify areas we can take advantage of manipulators to Custom Manipulators: Where we should take advantage of manipulators 2017-06-19 03:40:54 +02:00

Some humble suggestions

Group offset Group.dupli_offset currently only adjustable manually through coordinate input or from 3D cursor position

If possible a "move-like" widget to manually place/snap the 3D cursor about the scene SpaceView3D.cursor_location

Bezier curve extrusion value Curve.extrude, bonus points if it allowed snapping with the hypothetical widget snapping system

  • Misc per-vertex data like Bezier curve radius BezierSplinePoint.radius, tilt BezierSplinePoint.radius, mesh bevel weight, skin modifier radius, custom normals, etc
Some humble suggestions # Group offset `Group.dupli_offset` currently only adjustable manually through coordinate input or from 3D cursor position # If possible a "move-like" widget to manually place/snap the 3D cursor about the scene `SpaceView3D.cursor_location` # Bezier curve extrusion value `Curve.extrude`, bonus points if it allowed snapping with the hypothetical widget snapping system - Misc per-vertex data like Bezier curve radius `BezierSplinePoint.radius`, tilt `BezierSplinePoint.radius`, mesh bevel weight, skin modifier radius, custom normals, etc
Author
Owner

@duarteframos. thanks for the suggestions (undecided: 1, 3, postponed: 2, accepted: 4)

You mention custom-normals, this is fine but a bit too vague and I think should be part of bigger design task of how we should expose normal editing. So will leave this for now.

@duarteframos. thanks for the suggestions (undecided: 1, 3, postponed: 2, accepted: 4) You mention custom-normals, this is fine but a bit too vague and I think should be part of bigger design task of how we should expose normal editing. So will leave this for now.
Campbell Barton changed title from Custom Manipulators: Where we should take advantage of manipulators to Custom Manipulators: Where to take advantage of manipulators 2017-06-19 04:40:33 +02:00

Ah true, didn't think it all the way through about when/where to show said manipulators.

About group center perhaps make the widget visible when called from Properties Window > Object > Group and maybe add an option there like Set Group Center in the dropdown menu next to Set Offset from cursor (not an essential addition)

For curves I would envision something displayed at object center while the curve is active (selected too?) along the lines of the mockup bellow (may be togglable somewhere along with all other widgets)
BSE_CurveWidget.gif

Per vertex values should affect all selected I think, following the new 2.8 guideline that Alt no longer needs to be pressed to affect all selection.
Yes I imagine normal editing would require a larger project that would perhaps include a more comprehensive normal editor along the lines of what Blend4Web includes , definitely out of scope here

Ah true, didn't think it all the way through about when/where to show said manipulators. About group center perhaps make the widget visible when called from *Properties Window > Object > Group* and maybe add an option there like *Set Group Center* in the dropdown menu next to *Set Offset from cursor* (not an essential addition) For curves I would envision something displayed at object center while the curve is active (selected too?) along the lines of the mockup bellow (may be togglable somewhere along with all other widgets) ![BSE_CurveWidget.gif](https://archive.blender.org/developer/F635167/BSE_CurveWidget.gif) Per vertex values should affect all selected I think, following the new 2.8 guideline that `Alt` no longer needs to be pressed to affect all selection. Yes I imagine normal editing would require a larger project that would perhaps include a more comprehensive normal editor [along the lines of what Blend4Web includes ](https://www.blend4web.com/doc/en/normal_editor.html#normal-editor), definitely out of scope here

Added subscriber: @EjnarBrendsdal

Added subscriber: @EjnarBrendsdal
Author
Owner

@DuarteRamos - ok, see what you're getting at, still some Q's remaining.

  • Would this be object-mode, edit-mode... both?
  • How would this co-exist with the transform manipulator?
  • Would we want a way to adjust the bevel resolution too?
  • Would we have a similar manipulator for the bevel modifier or edit-mode tool? If not why not, what are the inherent differences?

One reason I'm a bit skeptical of this is - AFIACS - it gives incomplete access to the settings you would typically access when changing bevel. You would likely want to access [fill, bevel resolution... possibly offset].

Another is that the manipulator you edit is visually disconnected from what you're editing.

We could have a manipulator at the object center to adjust any number of properties - but at that point its really just an on-screen gizmo that replaces number buttons. After 2-3 of these its going to become confusing what settings you edit.

Also it could be annoying if the part of the curve you're interested in isn't at the object's center - this is a hint, IMHO that the manipulator should be re-considered.

Eg - the curve its self could show a highlighted rim which could be dragged up to add depth, once this is done the option to adjust bevel could be displayed around the curve rim.


Note that there are a lot of obvious cases where manipulators make sense, I wanted to avoid getting too caught up in the corner cases, so setting curve/bevel case as postponed since I think this needs some design work and its not really a high priority use-case AFAICS.

@DuarteRamos - ok, see what you're getting at, still some Q's remaining. - Would this be object-mode, edit-mode... both? - How would this co-exist with the transform manipulator? - Would we want a way to adjust the bevel resolution too? - Would we have a similar manipulator for the bevel modifier or edit-mode tool? If not why not, what are the inherent differences? One reason I'm a bit skeptical of this is - AFIACS - it gives incomplete access to the settings you would typically access when changing bevel. You would likely want to access [fill, bevel resolution... possibly offset]. Another is that the manipulator you edit is visually disconnected from what you're editing. We could have a manipulator at the object center to adjust any number of properties - but at that point its really just an on-screen gizmo that replaces number buttons. After 2-3 of these its going to become confusing what settings you edit. Also it could be annoying if the part of the curve you're interested in isn't at the object's center - this is a hint, IMHO that the manipulator should be re-considered. Eg - the curve its self could show a highlighted rim which could be dragged up to add depth, once this is done the option to adjust bevel could be displayed around the curve rim. ---- Note that there are a lot of obvious cases where manipulators make sense, I wanted to avoid getting too caught up in the corner cases, so setting curve/bevel case as postponed since I think this needs some design work and its not really a high priority use-case AFAICS.

Added subscriber: @stilobique

Added subscriber: @stilobique

Added subscriber: @sebastian_k

Added subscriber: @sebastian_k

I am not sure if this task includes the compositor, but I'll post it anyway

Node-Editor / Compositor:
Box/Ellipse Mask
It should be possible to change size and position of the Box/Ellipse Mask borders per widget.

Viewer Node:
The tile ordering center (which already looks like a widget) should be a draggable widget too.
Viewer Border (CTRL+B) is a good candidate for a widget as well.

Translate/Transform/Scale/Crop Nodes:
It should be possible to perform all transforms through a widget, like in any other image editing program.

Sun Beams:
There is a position input for the sub beams node, which could be widgetified as well.

I am not sure if this task includes the compositor, but I'll post it anyway **Node-Editor / Compositor:** Box/Ellipse Mask It should be possible to change size and position of the Box/Ellipse Mask borders per widget. Viewer Node: The tile ordering center (which already looks like a widget) should be a draggable widget too. Viewer Border (CTRL+B) is a good candidate for a widget as well. Translate/Transform/Scale/Crop Nodes: It should be possible to perform all transforms through a widget, like in any other image editing program. Sun Beams: There is a position input for the sub beams node, which could be widgetified as well.
Author
Owner

@sebastian_k, thanks for the suggestions, all seems reasonable, added to list.

Note that the viewer node is already widgitified in 2.8x, you need to have the viewer node selected though.

@sebastian_k, thanks for the suggestions, all seems reasonable, added to list. Note that the viewer node is already widgitified in 2.8x, you need to have the viewer node selected though.

Added subscriber: @hadrien

Added subscriber: @hadrien

Hi Campbell, hi everybody, here are some of my own ideas.

3DView

  • Bbone curve offsets and roll
    A pivot handle (like the bézier control point handles) as well as a rotation dial would control the bbone's curve offsets and roll in/out respectively. Right now, the workflow for manipulating those is quite convoluted - although as always it can be automated - and involves creating additional control bones that hook up to those properties through drivers. The downsides are it takes time, and needlessly complexifies rigs.
    There could also be additional dials for scale in/out and also something for easing in/out, although I can't come up with a good design idea for the latter (maybe some sort of slider between bone head and tail ?), and there is a risk it becomes a little crowded.

Graph Editor

  • Keyframe translate/rotate
    A simple X/Y translate and rotate manipulator for keyframes would be welcome.

I imagine the modeling operators are obvious targets for manipulators so I won't suggest them.

Lastly, I heartily second the 3DCursor placement idea.

Oh and I also noticed rmb/esc do not cancel manipulator operation, but maybe it's not supposed to ?

Hadrien

Hi Campbell, hi everybody, here are some of my own ideas. **3DView** - Bbone curve offsets and roll A pivot handle (like the bézier control point handles) as well as a rotation dial would control the bbone's curve offsets and roll in/out respectively. Right now, the workflow for manipulating those is quite convoluted - although as always it can be automated - and involves creating additional control bones that hook up to those properties through drivers. The downsides are it takes time, and needlessly complexifies rigs. There could also be additional dials for scale in/out and also something for easing in/out, although I can't come up with a good design idea for the latter (maybe some sort of slider between bone head and tail ?), and there is a risk it becomes a little crowded. **Graph Editor** - Keyframe translate/rotate A simple X/Y translate and rotate manipulator for keyframes would be welcome. I imagine the modeling operators are obvious targets for manipulators so I won't suggest them. Lastly, I heartily second the 3DCursor placement idea. *Oh and I also noticed rmb/esc do not cancel manipulator operation, but maybe it's not supposed to ?* Hadrien
Contributor

Added subscriber: @p2or

Added subscriber: @p2or
Contributor

A widgetified Render Border in 3D View (adjust the border bounds and its center) would be awesome too. Reference: https://developer.blender.org/T47267#435975.

A widgetified *Render Border in 3D View* (adjust the border bounds and its center) would be awesome too. Reference: https://developer.blender.org/T47267#435975.

Added subscriber: @Ko

Added subscriber: @Ko

Way to activate views from the top, side and others without touching the keyboard. As in this video: https://youtu.be/UlUssM353Rw?t=68

It will be useful if someone wants to use a Blender on a tablet device.

Way to activate views from the top, side and others without touching the keyboard. As in this video: https://youtu.be/UlUssM353Rw?t=68 It will be useful if someone wants to use a Blender on a tablet device.

In #51844#441270, @ideasman42 wrote:
@DuarteRamos - ok, see what you're getting at, still some Q's remaining.

  • Would this be object-mode, edit-mode... both?
  • How would this co-exist with the transform manipulator?

Good point, since bevel/extrude options can be controlled directly from object mode the widget would ideally also be accessible in object mode, but I can see viewport easily become crowded, so I'd totally understand if it was only available from edit mode

  • Would we want a way to adjust the bevel resolution too?
  • Would we have a similar manipulator for the bevel modifier or edit-mode tool? If not why not, what are the inherent differences?

Don't have a strong opinion about it; I see Bevel Resolution more like a "quality setting" rather than an actual geometric property, I'd be ok without a dedicated widget but if one could be squeezed in it certainly wouldn't hurt. Bevel modifier and mesh bevel operator could definitely benefit from reusing the same manipulator

One reason I'm a bit skeptical of this is - AFIACS - it gives incomplete access to the settings you would typically access when changing bevel. You would likely want to access [fill, bevel resolution... possibly offset].

Another is that the manipulator you edit is visually disconnected from what you're editing.

We could have a manipulator at the object center to adjust any number of properties - but at that point its really just an on-screen gizmo that replaces number buttons. After 2-3 of these its going to become confusing what settings you edit.

Also it could be annoying if the part of the curve you're interested in isn't at the object's center - this is a hint, IMHO that the manipulator should be re-considered.

Eg - the curve its self could show a highlighted rim which could be dragged up to add depth, once this is done the option to adjust bevel could be displayed around the curve rim.


Note that there are a lot of obvious cases where manipulators make sense, I wanted to avoid getting too caught up in the corner cases, so setting curve/bevel case as postponed since I think this needs some design work and its not really a high priority use-case AFAICS.

Understood, don't want to enforce the idea too hard here either, not so sure myself either, and I understand it is quite an unpopular modelling method.
Anyway just one final attempt, are hover-only widgets possible with the current system? I mean something that only shows up when hovering a certain object or sub-object (I think I've seen them in action in face maps widgets).
Bezier Curve widgets could be something that only shows up when hovering an existing curve vertex in object mode, preferably aligned to local curve normal, that way there is a direct correlation between extrude/offset/bevel values and resulting geometry, and won't collide as easily with other transform widgets.

BlenderDeveloper_CurveWidget00.gif

> In #51844#441270, @ideasman42 wrote: > @DuarteRamos - ok, see what you're getting at, still some Q's remaining. > > - Would this be object-mode, edit-mode... both? > - How would this co-exist with the transform manipulator? Good point, since bevel/extrude options can be controlled directly from object mode the widget would ideally also be accessible in object mode, but I can see viewport easily become crowded, so I'd totally understand if it was only available from edit mode > - Would we want a way to adjust the bevel resolution too? > - Would we have a similar manipulator for the bevel modifier or edit-mode tool? If not why not, what are the inherent differences? Don't have a strong opinion about it; I see *Bevel Resolution* more like a "quality setting" rather than an actual geometric property, I'd be ok without a dedicated widget but if one could be squeezed in it certainly wouldn't hurt. Bevel modifier and mesh bevel operator could definitely benefit from reusing the same manipulator > One reason I'm a bit skeptical of this is - AFIACS - it gives incomplete access to the settings you would typically access when changing bevel. You would likely want to access [fill, bevel resolution... possibly offset]. > > Another is that the manipulator you edit is visually disconnected from what you're editing. > > We could have a manipulator at the object center to adjust any number of properties - but at that point its really just an on-screen gizmo that replaces number buttons. After 2-3 of these its going to become confusing what settings you edit. > > Also it could be annoying if the part of the curve you're interested in isn't at the object's center - this is a hint, IMHO that the manipulator should be re-considered. > > Eg - the curve its self could show a highlighted rim which could be dragged up to add depth, once this is done the option to adjust bevel could be displayed around the curve rim. > > ---- > > Note that there are a lot of obvious cases where manipulators make sense, I wanted to avoid getting too caught up in the corner cases, so setting curve/bevel case as postponed since I think this needs some design work and its not really a high priority use-case AFAICS. Understood, don't want to enforce the idea too hard here either, not so sure myself either, and I understand it is quite an unpopular modelling method. Anyway just one final attempt, are hover-only widgets possible with the current system? I mean something that only shows up when hovering a certain object or sub-object (I think I've seen them in action in face maps widgets). Bezier Curve widgets could be something that only shows up when hovering an existing curve vertex in object mode, preferably aligned to local curve normal, that way there is a direct correlation between extrude/offset/bevel values and resulting geometry, and won't collide as easily with other transform widgets. ![BlenderDeveloper_CurveWidget00.gif](https://archive.blender.org/developer/F635836/BlenderDeveloper_CurveWidget00.gif)

Added subscriber: @Januz

Added subscriber: @Januz

A couple of ideas:

3D View: Camera Focal Length
This could be done with an icon in front of the camera that can be dragged away to increase the focal length. It would be great if it could also optionally display a translucent cone like spot lamps do. It would be easier to determine what's in front of the camera when changing focal lenghts.

3D View: Wind Force Field
Wind fields already dispaly an arrow, we could drag that arrow to change the force's strength.

A couple of ideas: **3D View: Camera Focal Length** This could be done with an icon in front of the camera that can be dragged away to increase the focal length. It would be great if it could also optionally display a translucent cone like spot lamps do. It would be easier to determine what's in front of the camera when changing focal lenghts. **3D View: Wind Force Field** Wind fields already dispaly an arrow, we could drag that arrow to change the force's strength.
Member

Added subscriber: @Blendify

Added subscriber: @Blendify
Member

In #51844#441327, @Ko wrote:
Way to activate views from the top, side and others without touching the keyboard. As in this video: https://youtu.be/UlUssM353Rw?t=68

It will be useful if someone wants to use a Blender on a tablet device.

Please refrane for saying "we should implement x from y software". We should try to come up with our own ideas and not copy others.
However, I do love their manuplator widget and it would indeed be nice to have something like that of our own.

> In #51844#441327, @Ko wrote: > Way to activate views from the top, side and others without touching the keyboard. As in this video: https://youtu.be/UlUssM353Rw?t=68 > > It will be useful if someone wants to use a Blender on a tablet device. Please refrane for saying "we should implement x from y software". We should try to come up with our own ideas and not copy others. However, I do love their manuplator widget and it would indeed be nice to have something like that of our own.
Member

Suggestions:

VSE Properties: Strip transform, rotation, backdrop.

Suggestions: VSE Properties: Strip transform, rotation, backdrop.

Added subscriber: @rocketman

Added subscriber: @rocketman

Suggestion: Manipulators on Camera and Lamp objects should be accessed by entering Edit Mode for these objects.
For instance, one could select a Spot Lamp and press Tab to enter Edit Mode, which would expose the manipulators for size, angle, and falloff. These would be hidden in object mode so as to avoid clutter. Entering edit mode on a Camera could expose manipulators for viewing angle, shift, focus distance and clipping.

Suggestion: Manipulators on Camera and Lamp objects should be accessed by entering Edit Mode for these objects. For instance, one could select a Spot Lamp and press Tab to enter Edit Mode, which would expose the manipulators for size, angle, and falloff. These would be hidden in object mode so as to avoid clutter. Entering edit mode on a Camera could expose manipulators for viewing angle, shift, focus distance and clipping.
Author
Owner

@Januz, 3D View: Camera Focal Length & 3D View: Wind Force Field are done already.

@rocketman camera FOV and Spot size are done already. Although not falloff and not using modes.

Camera DOF is done too but has some bug that needs fixing still.

@Blendify. sequencer backdrop was done but removed, can be added back again. Sequencer transform seems reasonable.

@Januz, 3D View: Camera Focal Length & 3D View: Wind Force Field are done already. @rocketman camera FOV and Spot size are done already. Although not falloff and not using modes. Camera DOF is done too but has some bug that needs fixing still. @Blendify. sequencer backdrop was done but removed, can be added back again. Sequencer transform seems reasonable.

Added subscriber: @MichaelParucha

Added subscriber: @MichaelParucha

Added subscriber: @SeanKennedy

Added subscriber: @SeanKennedy

@sebastian_k Thanks for the Node-Editor / Compositor suggestions!
@SeanKennedy do you have some more suggestions for compositor widgets?

@sebastian_k Thanks for the Node-Editor / Compositor suggestions! @SeanKennedy do you have some more suggestions for compositor widgets?

@campbellbarton. A better control of the plane track in the movie clip editor would be cool. Aspect ratio, width and height and rotating.

@campbellbarton. A better control of the plane track in the movie clip editor would be cool. Aspect ratio, width and height and rotating.
Member

Added subscriber: @StephenLeger

Added subscriber: @StephenLeger
Member

generic Size control
Arc radius
Arc angle

From python perspectice, definitely need:

  • a way to set draw origin, orientation, constraints
  • may draw editable value as text

callbacks shoud return both absolute and relative changes done

  • callback on change
  • callback to draw placeholders when needed
  • callback on cancel
  • callback on exit

feel free to take a look at
https://github.com/s-leger/archipack/wiki/Manipulable-%3F
https://www.youtube.com/watch?v=61a-ZaQzeVI

generic Size control Arc radius Arc angle From python perspectice, definitely need: - a way to set draw origin, orientation, constraints - may draw editable value as text callbacks shoud return both absolute and relative changes done - callback on change - callback to draw placeholders when needed - callback on cancel - callback on exit feel free to take a look at https://github.com/s-leger/archipack/wiki/Manipulable-%3F https://www.youtube.com/watch?v=61a-ZaQzeVI

Added subscriber: @JorgeLosilla

Added subscriber: @JorgeLosilla

3d View: Camera Guides Now we have a few composition guides when entering camera view mode. It will be usefull to give the ability to create custom guides, something similar to what 2d software for vector creation or image manipulation has. This will be very usefull for arranging compostions, specially in motion graphics.

**3d View: Camera Guides** Now we have a few composition guides when entering camera view mode. It will be usefull to give the ability to create custom guides, something similar to what 2d software for vector creation or image manipulation has. This will be very usefull for arranging compostions, specially in motion graphics.

Added subscriber: @zeauro

Added subscriber: @zeauro

3D View : Texture Mapping
For a mapping node taking as an entry generated or world coordinates (an origin that correspond to point easy to identify in 3DView) , we can think of a manipulator in 3D view to set offset, scale or rotation of the coordinates.
There could be a manipulator visible only in camera view for Window or Camera coordinates.

3D View : Simple Deform modifier
People are used to set origin of object at center of geometry because blender's snap menu encourages them to do it. But a simple bend requires to have it at basis of the object or to use an empty.
So, doing a simple bend becomes counter-intuitive especially when you want a localized bend only on a part of the object.
You just not have to move limits. You have to adjust empty's location to avoïd a rotation of the whole mesh.
It is probably not simpler case but imho, as modifier that is hard to understand, simple deform modifier is a priority.

**3D View : Texture Mapping** For a mapping node taking as an entry generated or world coordinates (an origin that correspond to point easy to identify in 3DView) , we can think of a manipulator in 3D view to set offset, scale or rotation of the coordinates. There could be a manipulator visible only in camera view for Window or Camera coordinates. **3D View : Simple Deform modifier** People are used to set origin of object at center of geometry because blender's snap menu encourages them to do it. But a simple bend requires to have it at basis of the object or to use an empty. So, doing a simple bend becomes counter-intuitive especially when you want a localized bend only on a part of the object. You just not have to move limits. You have to adjust empty's location to avoïd a rotation of the whole mesh. It is probably not simpler case but imho, as modifier that is hard to understand, simple deform modifier is a priority.

For all suggestions that relate to constraints/modifiers : I like the idea, but when is the manipulator displayed / how is it toggled ?

For all suggestions that relate to constraints/modifiers : I like the idea, but when is the manipulator displayed / how is it toggled ?

@ Hadrien Brissaud, I think that we could add an icon or a Modify toggle in the Apply/Copy buttons line.

Tools :
3DView : Rotate Edge or UVs or Colors

When dealing with Ngons, we can need to do several iteration of Rotate Edges.
And for rotating UVs and colors, we have another opperator to Reverse UVs and Reverse Colors.
An interactive manipulator could decrease number of calls and number of operators.

3D View : Proportionnal Editing
Vector would be a moved arrow for translation and scaling. There would be a circle for proportionnal size.
and between both an horizontal line could be modified used as a curve widget to adjust falloff.

@ Hadrien Brissaud, I think that we could add an icon or a Modify toggle in the Apply/Copy buttons line. **Tools : 3DView : Rotate Edge or UVs or Colors** When dealing with Ngons, we can need to do several iteration of Rotate Edges. And for rotating UVs and colors, we have another opperator to Reverse UVs and Reverse Colors. An interactive manipulator could decrease number of calls and number of operators. **3D View : Proportionnal Editing** Vector would be a moved arrow for translation and scaling. There would be a circle for proportionnal size. and between both an horizontal line could be modified used as a curve widget to adjust falloff.
Member

Node-Editor / Compositor:
Corner Pin node:
This node desperately needs a widget. Pretty simple widget, just four corners. I suppose it could also have the soon-to-be-standard transform widget in the center of it, as well (that would be a nice bonus!)

Movie Clip Editor:
Rotoscoping:
It would be great to have a box widget that appeared when ever more than one control point was selected. This widget would let you move, rotate, scale, and warp the selected control point positions.

Also, there should be a hotkey to turn on/off widget visibility, at least in the compositor. This is necessary to get a clear, unobstructed view of the composited image.

I can demo any of these types of functions if necessary.

**Node-Editor / Compositor:** Corner Pin node: This node desperately needs a widget. Pretty simple widget, just four corners. I suppose it could also have the soon-to-be-standard transform widget in the center of it, as well (that would be a nice bonus!) **Movie Clip Editor:** Rotoscoping: It would be great to have a box widget that appeared when ever more than one control point was selected. This widget would let you move, rotate, scale, and warp the selected control point positions. Also, there should be a hotkey to turn on/off widget visibility, at least in the compositor. This is necessary to get a clear, unobstructed view of the composited image. I can demo any of these types of functions if necessary.
Author
Owner

Updated main document, notes:

  • There are some suggestions that IMHO are basically moving buttons from the toolbar into the 3D view, for example - the number of steps for "Rotate Edge" or Rotate UVs/Colors" ~ To justify having a manipulator there should be a visual connection. OR, if accessing the toolbar isn't convenient - that should be solved separately and not by moving UI to manipulators.

    Correction, if you were to click on one corner, then drag the cursor to another corner, this would make rotate UV's/Color into a useful manipulator. Perhaps this is what was meant?

  • Other suggestions suffer from a similar problem, inset or bevel for example - while you might want to edit them in the 3D view, we would probably want the manipulator to be the geometry thats being modified (eg, click on any edge to drag the bevel back and fourth). This is reasonable but a bit more involved. I'm not against but this isn't low hanging fruit. Added note about this under "Scope of Widgets" * #47345

  • Manipulators types will need the ability to be toggled, some off by default. Ability to hook up to hotkeys is always there.

Replies

  • @DuarteRamos Curve bevel is IMHO example that raises questions on scope-of-widgets, see: #47345 - not against but think it's not an obvious early addition.
  • @MichaelParucha Added track manipulator.
  • @StephenLeger API design is outside scope of this task, although I'm currently working on this and will have a proposed API this week. Not that you can write your own widgets in Python so arent limited to ones Blender defines.
  • @JorgeLosilla Not sure about Camera guides, seems like you would end up wanting to keep them turned off by default so they don't get in the way of you're view interaction, so having to enable, modify, then disable - seems like it could be more hassle then simply editing as buttons.
  • @zeauro texture mapping could be handy, though similar to constraints/modifiers, how to expose manipulators for nodes in the 3D view needs some design.
  • @hadrien How to choose which modifier(s) to show manipulators for is indeed an issue. Can imagine some ways it can be done. I first wanted to see if this is worth doing a all (if there are only 1-2 modifiers where this is marginally useful... we could better ignore it)
  • @zeauro Rotate UV's seems case where manipulator is simply replacing number buttons with no real advantage. Rotate edge could be made into a manipulator but it would have to work differently to how it does now (perhaps you grab the end-points and drag them around the ngon). Currently edge rotate supports rotating multiple edges at once. So this might be better solved by having a mode/tool where you can click on edges and move their connectivity ... which isn't so much related to the current edge-rotate tool.
  • @SeanKennedy Good suggestions, added. Question though - is this for tracking points or mask too?
Updated main document, notes: * There are some suggestions that IMHO are basically moving buttons from the toolbar into the 3D view, for example - the number of steps for "Rotate Edge" or Rotate UVs/Colors" ~ To justify having a manipulator there should be a visual connection. OR, if accessing the toolbar isn't convenient - that should be solved separately and not by moving UI to manipulators. *Correction, if you were to click on one corner, then drag the cursor to another corner, this would make rotate UV's/Color into a useful manipulator. Perhaps this is what was meant?* * Other suggestions suffer from a similar problem, inset or bevel for example - while you might want to edit them in the 3D view, we would probably want the manipulator to be the geometry thats being modified (eg, click on any edge to drag the bevel back and fourth). This is reasonable but a bit more involved. I'm not against but this isn't low hanging fruit. Added note about this under "Scope of Widgets" * #47345 * Manipulators types will need the ability to be toggled, some off by default. Ability to hook up to hotkeys is always there. Replies * @DuarteRamos Curve bevel is IMHO example that raises questions on scope-of-widgets, see: #47345 - not against but think it's not an obvious early addition. * @MichaelParucha Added track manipulator. * @StephenLeger API design is outside scope of this task, although I'm currently working on this and will have a proposed API this week. Not that you can write your own widgets in Python so arent limited to ones Blender defines. * @JorgeLosilla Not sure about Camera guides, seems like you would end up wanting to keep them turned off by default so they don't get in the way of you're view interaction, so having to enable, modify, then disable - seems like it could be more hassle then simply editing as buttons. * @zeauro texture mapping could be handy, though similar to constraints/modifiers, how to expose manipulators for nodes in the 3D view needs some design. * @hadrien How to choose which modifier(s) to show manipulators for is indeed an issue. Can imagine some ways it can be done. I first wanted to see if this is worth doing a all (if there are only 1-2 modifiers where this is marginally useful... we could better ignore it) * @zeauro Rotate UV's seems case where manipulator is simply replacing number buttons with no real advantage. Rotate edge could be made into a manipulator but it would have to work differently to how it does now (perhaps you grab the end-points and drag them around the ngon). Currently edge rotate supports rotating multiple edges at once. So this might be better solved by having a mode/tool where you can click on edges and move their connectivity ... which isn't so much related to the current edge-rotate tool. * @SeanKennedy Good suggestions, added. Question though - is this for tracking points or mask too?
Member

In #51844#441528, @ideasman42 wrote:

  • @SeanKennedy Good suggestions, added. Question though - is this for tracking points or mask too?

My suggestion for the Movie Clip Editor is only for rotoscoping. We currently have a small dot in the center of a mask that allows us to move all points together as one, but having a bounding box around all selected points could allow deformation to the shape as a whole, such as non-uniform scaling or warping. I'm actually content with tracking points and how they're controlled without widgets.

> In #51844#441528, @ideasman42 wrote: > * @SeanKennedy Good suggestions, added. Question though - is this for tracking points or mask too? My suggestion for the Movie Clip Editor is only for rotoscoping. We currently have a small dot in the center of a mask that allows us to move all points together as one, but having a bounding box around all selected points could allow deformation to the shape as a whole, such as non-uniform scaling or warping. I'm actually content with tracking points and how they're controlled without widgets.

Added subscriber: @lowercase

Added subscriber: @lowercase

the missing manipulator is one that can be used to move object origin
for modifiers it would be nice if you could just skip using empties, I see you mentioned rotation for array
extrude_repeat operator would be useful with a transform manipulator, like a matrix extrude

the missing manipulator is one that can be used to move object origin for modifiers it would be nice if you could just skip using empties, I see you mentioned rotation for array extrude_repeat operator would be useful with a transform manipulator, like a matrix extrude

Correction, if you were to click on one corner, then drag the cursor to another corner, this would make rotate UV's/Color into a useful manipulator. Perhaps this is what was meant?

Yes. That was what I mean.

How to choose which modifier(s) to show manipulators for is indeed an issue. Can imagine some ways it can be done. I first wanted to see if this is worth doing a all (if there are only 1-2 modifiers where this is marginally useful... we could better ignore it)

We are currently adding lots of empties in our scenes just to use modifiers.
I thought that these ones would obviously by benefit of a manipulator help to decrease complexity in outliner.

Mirror (symmetry plane)
Cast (center)
Hook (center, radius, strength)
Vertex Weight Proximity ( target )

There are also those requiring empties to give a direction.
Normal Edit
UVProject

And those who are requiring two locations to work.
Warp and UVWarp.

In all those cases, it makes sense to keep a field to use an object meaningful in scene context.
But in most of times, we don't relate their use to renderable objects.
It could be frustrating to add an empty for modeling to delete it when modifier is applied.
And for animation, most of them do not recognize bones as a valid target.

And if we have manipulators useful for texture mapping, any modifier using textures will use them.

I have no doubt that manipulators for modifiers would be used.
When you are adding a modifier by menu ; you will instantly tweak its settings.
It seems logical to enable manipulator display at addition and to limit it to active object in case of multiple selection.
I don't see where is the problem to have manipulator display toggle as a modifier setting.

A manipulator display per modifier means ability to show several at same time in 3DView.
It would be a nightmare without different possible looks for manipulators like what exists for empties.
But if work is done in 3DView, it means no more scrolling in modifier stack.

But maybe, it is too much effort to finally convert modifiers to nodes.

> Correction, if you were to click on one corner, then drag the cursor to another corner, this would make rotate UV's/Color into a useful manipulator. Perhaps this is what was meant? Yes. That was what I mean. > How to choose which modifier(s) to show manipulators for is indeed an issue. Can imagine some ways it can be done. I first wanted to see if this is worth doing a all (if there are only 1-2 modifiers where this is marginally useful... we could better ignore it) We are currently adding lots of empties in our scenes just to use modifiers. I thought that these ones would obviously by benefit of a manipulator help to decrease complexity in outliner. Mirror (symmetry plane) Cast (center) Hook (center, radius, strength) Vertex Weight Proximity ( target ) There are also those requiring empties to give a direction. Normal Edit UVProject And those who are requiring two locations to work. Warp and UVWarp. In all those cases, it makes sense to keep a field to use an object meaningful in scene context. But in most of times, we don't relate their use to renderable objects. It could be frustrating to add an empty for modeling to delete it when modifier is applied. And for animation, most of them do not recognize bones as a valid target. And if we have manipulators useful for texture mapping, any modifier using textures will use them. I have no doubt that manipulators for modifiers would be used. When you are adding a modifier by menu ; you will instantly tweak its settings. It seems logical to enable manipulator display at addition and to limit it to active object in case of multiple selection. I don't see where is the problem to have manipulator display toggle as a modifier setting. A manipulator display per modifier means ability to show several at same time in 3DView. It would be a nightmare without different possible looks for manipulators like what exists for empties. But if work is done in 3DView, it means no more scrolling in modifier stack. But maybe, it is too much effort to finally convert modifiers to nodes.

Added subscriber: @fsiddi

Added subscriber: @fsiddi

@campbellbarton. I've added a screenshot to clarify what I mean by 'Plane Track' (Can be created with 4 tracks):
plane-track.png

@campbellbarton. I've added a screenshot to clarify what I mean by 'Plane Track' (Can be created with 4 tracks): ![plane-track.png](https://archive.blender.org/developer/F637785/plane-track.png)

In #51844#441369, @ideasman42 wrote:
@Januz, 3D View: Camera Focal Length & 3D View: Wind Force Field are done already.

Cool!
Will custom manipulators work on all editors? I think F-Curve modifiers could also use them. For instance changing the strength and scale of the noise modifier by dragging two points (or icons). In the envelope modifier the min/max settings for each control point could also be dragged (they are represented as lines and dots now). The same could be done with the limits modifier, drawing lines for min/max settings and making them draggable.

The widgets could be hidden by default and activated while the F-Curve modifier is being edited (by clicking on the dot icon).

> In #51844#441369, @ideasman42 wrote: > @Januz, 3D View: Camera Focal Length & 3D View: Wind Force Field are done already. > Cool! Will custom manipulators work on all editors? I think F-Curve modifiers could also use them. For instance changing the strength and scale of the noise modifier by dragging two points (or icons). In the envelope modifier the min/max settings for each control point could also be dragged (they are represented as lines and dots now). The same could be done with the limits modifier, drawing lines for min/max settings and making them draggable. The widgets could be hidden by default and activated while the F-Curve modifier is being edited (by clicking on the dot icon).

I think you missed my post above @ideasman42 because it got buried in a sea of equally awesome suggestions. :) I suggested bbone roll control in the 3dview, and translate manipulator in the graph editor.

Follow-up question : do manipulators support modifier key and numerical input ? Ctrl to snap, shift to toggle precision, etc. It would be nice for tools like extrude, edge slide.

I think you missed my post above @ideasman42 because it got buried in a sea of equally awesome suggestions. :) I suggested bbone roll control in the 3dview, and translate manipulator in the graph editor. Follow-up question : do manipulators support modifier key and numerical input ? Ctrl to snap, shift to toggle precision, etc. It would be nice for tools like extrude, edge slide.
Author
Owner

Note that some of the suggestions raise too many questions, that doesn't mean they're bad suggestions - I just like to first focus more on clear-cut cases early on.

Also, my own opinion on your suggestions isn't in "final word" - other developers can work on implementing manipulators for parts of Blender they maintain.
Further, development on this area will be on-going and doesn't depend on this task which is just to get an initial list of suggestions for developers to work on.


  • @lowercase, manipulator for object origin - not sure of this, added to "Undecided".
Noted using manipulators + positions instead of modifiers.

@zeauro - uv rotate using a manipulator is likely to be quite awkward - for a single large ngon it can work. But for many faces its going to cause some overly dense manipulator cluster... again - maybe some nice design can workaround this, but IMHO this is moving towards rewriting a tool to use manipulators.

Re: your comments on modifiers, something like this can work. Note that currently only active objects manipulators are displayed, which prevents manipulators flooding the view too much.
  • @Januz, fcurve modifier noise AFAICS suffers similar problem to other suggestions - that its basically on-screen buttons.
besides amplitude and offset, adjusting the values as manipulators doesnt make so much sense.
Your other points about min/max limit modifiers seem reasonable but not really helping user productivity so much if they need to be manually enabled/disabled.
Added f-curve manipulator, although would like to see some design & discussion with animators.
Manipulators do support Shift for precise adjustment, currently not Ctrl for snap, but this will likely be added. (Noted this as design issue in T47345 "Snap System").
Note that some of the suggestions raise too many questions, that doesn't mean they're bad suggestions - I just like to first focus more on clear-cut cases early on. Also, my own opinion on your suggestions isn't in *"final word"* - other developers can work on implementing manipulators for parts of Blender they maintain. Further, development on this area will be on-going and doesn't depend on this task which is just to get an initial list of suggestions for developers to work on. ---- * @lowercase, manipulator for object origin - not sure of this, added to "Undecided". ``` Noted using manipulators + positions instead of modifiers. ``` @zeauro - uv rotate using a manipulator is likely to be quite awkward - for a single large ngon it can work. But for many faces its going to cause some overly dense manipulator cluster... again - maybe some nice design can workaround this, but IMHO this is moving towards rewriting a tool to use manipulators. ``` Re: your comments on modifiers, something like this can work. Note that currently only active objects manipulators are displayed, which prevents manipulators flooding the view too much. ``` * @Januz, fcurve modifier noise AFAICS suffers similar problem to other suggestions - that its basically on-screen buttons. ``` besides amplitude and offset, adjusting the values as manipulators doesnt make so much sense. ``` ``` Your other points about min/max limit modifiers seem reasonable but not really helping user productivity so much if they need to be manually enabled/disabled. ``` * @hadrien - Added b-bone roll. ``` Added f-curve manipulator, although would like to see some design & discussion with animators. ``` ``` Manipulators do support Shift for precise adjustment, currently not Ctrl for snap, but this will likely be added. (Noted this as design issue in T47345 "Snap System"). ```

Added subscriber: @RayMairlot

Added subscriber: @RayMairlot

I see @p2or suggested the Render Border as good candidate for widgetification (+1 from me), but I think maybe you missed this suggestion @ideasman42?

In #51844#441298, @p2or wrote:
A widgetified Render Border in 3D View (adjust the border bounds and its center) would be awesome too. Reference: https://developer.blender.org/T47267#435975.

I see @p2or suggested the Render Border as good candidate for widgetification (+1 from me), but I think maybe you missed this suggestion @ideasman42? > In #51844#441298, @p2or wrote: > A widgetified *Render Border in 3D View* (adjust the border bounds and its center) would be awesome too. Reference: https://developer.blender.org/T47267#435975.
Member

Added subscriber: @pablovazquez

Added subscriber: @pablovazquez

Added subscriber: @satishgoda1

Added subscriber: @satishgoda1

Some thought on the F-Curve: Key-Frame Manipulator
As an animator (mostly working in Maya for jobs, and Blender for personal stuff, so might lack experience with Blender's animation tools overall) the reasoning behind this manipulator is I find a little difficult to move several keyframes at once, especially when it's on a single axis - shortcut G+X/Y works but it makes editing in the graph tiring when tweaking loads of keyframes - either adjusting values (moving on y) or adjusting timing (moving on x) on an entire shot can feel taxing after a short while. Adjusting a single keyframe is fine with a tablet since middle-clicking during a transform will snap to the closest axis (and you can do that with a tablet pen), but moving several keyframes requires hitting G anyway.
So, a 2d manipulator like the one in the 3d view would be welcome. It doesn't have to look like two perpendicular arrows - it could be a box encompassing the current selection or something different. It should allow for moving independently on a single axis as well as freely on both axes. Maybe it could allow for scaling as well by dragging its corners. If it ends up taking that kind of shape it could get in the way of selection so it's probably important that it stays toggle-able.

Currently I don't see the need for a keyframe handle manipulator, since click+dragging/rotating with individual centers works well, but others might see it differently.

Some thought on the **F-Curve: Key-Frame Manipulator** As an animator (mostly working in Maya for jobs, and Blender for personal stuff, so might lack experience with Blender's animation tools overall) the reasoning behind this manipulator is I find a little difficult to move several keyframes at once, especially when it's on a single axis - shortcut G+X/Y works but it makes editing in the graph tiring when tweaking loads of keyframes - either adjusting values (moving on y) or adjusting timing (moving on x) on an entire shot can feel taxing after a short while. Adjusting a single keyframe is fine with a tablet since middle-clicking during a transform will snap to the closest axis (and you can do that with a tablet pen), but moving several keyframes requires hitting G anyway. So, a 2d manipulator like the one in the 3d view would be welcome. It doesn't have to look like two perpendicular arrows - it could be a box encompassing the current selection or something different. It should allow for moving independently on a single axis as well as freely on both axes. Maybe it could allow for scaling as well by dragging its corners. If it ends up taking that kind of shape it could get in the way of selection so it's probably important that it stays toggle-able. Currently I don't see the need for a keyframe handle manipulator, since click+dragging/rotating with individual centers works well, but others might see it differently.
Author
Owner

@hadrien, thanks for your feedback, though I'm not sure how manipulators will make moving multiple keyframes (which aren't on the same axis) any easier.

Just a note that I think adding a manipulator to the f-curve editor should be done carefully with feedback from animators, unlike other areas I don't think this is as simple as adding some handles to move the keyframes around (as with the 3d view).

@hadrien, thanks for your feedback, though I'm not sure how manipulators will make moving multiple keyframes *(which aren't on the same axis)* any easier. Just a note that I think adding a manipulator to the f-curve editor should be done carefully with feedback from animators, unlike other areas I don't think this is as simple as adding some handles to move the keyframes around (as with the 3d view).

This new orientation manipulator for lamps is too small. And sometimes it is not visible on the screen at all. The arrow that changes the size of the spot is also not too obvious (maybe it's better to use a large circle instead of it for the spot lamp?)

This new orientation manipulator for lamps is too small. And sometimes it is not visible on the screen at all. The arrow that changes the size of the spot is also not too obvious (maybe it's better to use a large circle instead of it for the spot lamp?)
Author
Owner

@Ko, increased the size and view-align the manipulator. 464c045b31

@Ko, increased the size and view-align the manipulator. 464c045b31

@ideasman42 what do you mean by "which aren't on the same axis" ? I think simply using a click-and-drag rather than a keystroke is already much easier - this was the rationale behind pie menus iirc : less travel for the keyboard hand (it suddenly strikes me how primitives input devices still are...). I agree that neither this one, nor any other manipulator should be designed without the input of several of the target users.

Probably needs a mockup or two, I'll see if I can come up with a nice design.

Little feedback on the rotate manipulator - there's just one hiccup as far as I'm concerned : the view aligned circle (white) should be drawn bigger - right now it conflicts easily with other axes as well as trackball rotate.
And a remark on the translate one : shouldn't the hotspot for the central circle fill the entire circle instead of being just the periphery ? This is the way it's always been iirc, but it always felt kind of unusual to me, bit unintuitive having to target the circle instead of just hitting the center thoughtlessly, if you know what I mean. Now the center is used for trackball rotate when rotate manipulator is also active, but personally I'd prefer having it as hotspot for translate - that being said it should probably go hand in hand with a slight decrease in radius to avoid stealing too much area for trackball rotate.

@ideasman42 what do you mean by "which aren't on the same axis" ? I think simply using a click-and-drag rather than a keystroke is already much easier - this was the rationale behind pie menus iirc : less travel for the keyboard hand (it suddenly strikes me how primitives input devices still are...). I agree that neither this one, nor any other manipulator should be designed without the input of several of the target users. Probably needs a mockup or two, I'll see if I can come up with a nice design. Little feedback on the rotate manipulator - there's just one hiccup as far as I'm concerned : the view aligned circle (white) should be drawn bigger - right now it conflicts easily with other axes as well as trackball rotate. And a remark on the translate one : shouldn't the hotspot for the central circle fill the entire circle instead of being just the periphery ? This is the way it's always been iirc, but it always felt kind of unusual to me, bit unintuitive having to target the circle instead of just hitting the center thoughtlessly, if you know what I mean. Now the center is used for trackball rotate when rotate manipulator is also active, but personally I'd prefer having it as hotspot for translate - that being said it should probably go hand in hand with a slight decrease in radius to avoid stealing too much area for trackball rotate.

Added subscriber: @AdamPreisler

Added subscriber: @AdamPreisler
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:26:25 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
22 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#51844
No description provided.