This thread serves a few purposes:
- Present the current design.
- Gather practical user feedback to find potential problems with the design and implementation (also see the known limitations below).
- Allow users to share their first tests and experiences with gizmos in a centralized place.
The design went through a few iterations already. Here, I’ll only describe the latest design that is also available in the patch.
A new gizmo can be added by simply inserting a new
Arrow Gizmo or
Dial Gizmo node. After inserting a gizmo node, the gizmo will show up in the viewport immediately.
One can already drag the gizmo in the viewport, but it controls no value and always jumps back to the origin. For the gizmo to control a value it has to be linked to
This may seem counter intuitive at first, and indeed, it introduces a new concept that is hinted at by the new link drawing style. This new link does not pass along any data. Instead its only purpose is to tell the gizmo node which value it should control.
When dragging the gizmo now, the value in the
Value node changes, but the gizmo still jumps back to the origin every time. This can solved by actually making the gizmo position dependent on the value.
It’s important that the controlled value is to the left of the gizmo node, because that allows us to use its value to affect the position and direction of the gizmo. With gizmos, there is a fundamental two way dependency, where the value affects the position and the position also affects the value.
Since there is no actual data flow in these new kinds of links, only a very limited set of nodes is allowed to be used with them which will be explained below.
The limitation that only some nodes can be used with the
Value input socket does not apply to the
Direction sockets. All nodes can be used to compute those.
Now let’s modify the example a bit so that the gizmo controls the width of a grid.
When trying this example, you’ll see that the gizmo does not stay attached to the grid when moving it. That is because by default moving the gizmo by one unit will also change the controlled value by one unit. However, in this case the edge of the grid only moves at half the speed.
To fix this, we have to tell Blender how movements of the gizmo are converted to changes in the value. Fortunately, this is easy here, because the
Math node has special meaning to the gizmo nodes. The gizmo stays attached to the grid after simply connecting the
Divide node directly to the gizmo node.
With this change, Blender can infer automatically that the value should be modified by two units whenever the gizmo moves one unit. Only the
Multiply modes of the
Math node have this special behavior for now, which is enough for the large majority of use cases. It’s also possible to use an
Subtract node, but those won’t change the mapping.
We have already seen that gizmos can control
Value nodes. This section shows the other kinds of targets that can be controlled by gizmos already.
Just like the
Value node, one can also use a
Vector input node. However, since it outputs a vector and gizmos only control floats, one has to use the
Separate XYZ node. This example also shows that the
Vector Math node in
Scale mode can also be put between a gizmo node and its target.
Besides controlling values that are hardcoded in the node tree, it is also possible to connect group inputs to the gizmo node. This allows creating gizmos that change modifier inputs.
Gizmos that control group inputs can not only be used with modifier inputs, but also with group nodes. In the case below, the
Grid with Gizmo group comes with a gizmo that modifies its input.
Note that in this case, the group node has to be selected. Otherwise the gizmo won’t be shown.
In the current setup from above there is a problem when transforming the grid afterwards. While the grid moves, the gizmo stays at its original location.
To fix this, the gizmo nodes have a
Transform geometry output. This should be joined into the geometry that is controlled by the gizmo. Now, Blender has enough information two know that the gizmo should be transformed together with the grid. Typically, only people creating node group assets have to care about this. For people who use the assets, these transforms should work automatically.
Note that this only works within certain limitations, since Blender can not always figure out how changes to the geometry should map to changes in the gizmo transform. If there should still be a gizmo in such complex situations, it is better to just create a new gizmo and to compute its position manually.
Gizmo transforms are also propagated to instances. In the example below are two grids, the size of each is controlled with a separate gizmo. For instanced geometry, the gizmos only show for the first instance by convention for now. The image shows both gizmos, because both group nodes are selected.
You might have noticed already, that the gizmo nodes have a multi-input. This allows a single gizmo to control more than one values. This can be used to e.g. build a gizmo that controls both the X and Y size of a grid while still keeping two independent inputs.
In this example, both inputs are changed by the same amount when the gizmo moves. However, it’s also possible to change them by different amounts.
Only a small set of gizmo shapes is supported initially. One goal to keep in mind is that gizmos of different node group assets should look and feel similar.
A similar constraint exists for colors. Currently, one can choose from a fixed set of colors that is used throughout Blender and can be modified in the theme settings.
There are a few rules that determine which gizmos are visible in the viewport. A gizmo is visible if any of these is true:
- It controls an input of the active modifier of the active object.
- The gizmo node is in one of the open node editors.
- The gizmo controls a value in a selected node in an open node editor.
These rules could be fine tuned with some user feedback. Manual control over gizmo visibility might also be added at some point.
While we are fairly confident in the overall design already, some UI decisions are still open:
- How do we differentiate “normal” links and links that are used to connect gizmo nodes to the value they control?
- Do we have to show that a node contains gizmos and if yes, how?
- Do we have to show which input values have a gizmo and if yes, how?
Dial Gizmobe renamed to something else? For example,
These limitations below are known and don’t need to be mentioned again. They are not fundamental limitations of the design but are intentionally left out for now.
- Only a fixed set of gizmos shapes is supported that are widely used in Blender. Custom shapes are not possible.
- Only a fixed set of theme colors are supported.
- Can’t create a dynamic number of gizmos, e.g. one per vertex.
- The base transform of a gizmo can not change while the gizmo is being dragged.