The way we use viewer nodes in Geometry Nodes and the compositor does not feel ideal currently. This document proposes a modification the how we position viewer nodes that might be a better trade-off between the various constraints.
Scope: Temporary Viewers
Recently, the ability to add shortcuts to viewer nodes was added (PR). I’ll call viewers set up in this way persistent viewers, because they are manually managed and are intended to be reused without changing what’s connected to them.
This document is about temporary viewers. Those are intended to be quick to set-up and remove. The inputs to those viewers changes all the time.
Current Viewer Nodes
Currently, the main way to use viewer nodes is to ctrl+shift+click on a node or socket to link it to a viewer node which becomes active automatically. If no viewer node exists yet, a new one is inserted.
In Geometry Nodes, the viewer node can also be used to visualize fields. Therefore it has a geometry and a field input. Depending on what socket one clicks on, it will either be connected to the geometry or the field input.
The main problem with this approach is that the node has to positioned in the node tree somewhere. Currently, the viewer node automatically positions itself whenever activating it through ctrl+shift+click. This can be annoying because the viewer node is sometimes jumping around more than feels necessary and people still end up moving it around manually.
Earlier Alternatives
Before we had the current design, we did have a few design iterations already which had downsides too.
No Automatic Repositioning
Before the automatic positioning was implemented, the viewer was only positioned when it was first inserted. Afterwards, it was the user’s responsibility to move it around. This is also far from ideal, because in practice the viewer node usually ended up far outside the current view and was thus invisible. Consequently, any settings on the viewer node are also invisible.
Viewer Flag on Nodes
In earlier versions of Geometry Nodes, we had a toggle in the node header. When enabled, the output of that node would be viewed. This has the advantage that no additional viewer node is needed that takes up space and would need to be moved around.
There are some significant downsides to this approach:
- Can’t connect multiple values to the viewer.
- Can’t choose which output socket to connect to the viewer.
- No obvious place where viewer settings should be placed.
- Takes up space in the header of each node.
This approach did have the advantage that we could make it possible to view any output in a linked node tree, because that toggle could be made modifiable even on linked data. That said, we can probably manage to make that work with viewer nodes too with a little more effort.
Proposal
The proposal is to make temporary viewer nodes sticky in the node editor. By that I mean that it is fixed in screen space somewhere on the right side of the node editor, even if the node editor moves underneath it.
We might want to change the drawing of the viewer node a little bit to make it look more detached from the underlying node editor. A simple way to achieve that might be to change the outline and play with the drop shadow.
Additionally, it might make sense to change the drawing of sockets and links connected to the viewer to make those more obvious, but I don’t have any specific proposal.
Beyond that, all the existing behavior of viewer nodes remain unchanged. It can still just be selected and removed like any other node.
This little demo was done using #138247 - WIP: Nodes: Sticky Viewer Nodes - blender - Blender Projects.
Outcome
Sticky nodes are a new concept and might therefore feel a bit weird at first. However, there are quite a few advantages to this approach which may make it worth it:
- Anyone can stop worrying about the position of the viewer node. It’s not necessary anymore to move it around manually.
- By making it sticky, it’s also less of an issue if it overlaps with other nodes that happen to be underneath it.
- Since the viewer position stays the same, there will also be no unexpected jumping of the viewer anymore.
- The viewer node is always visible and thus it’s always obvious whether it is currently used and which of its inputs are linked.
- The settings on the viewer node are always accessible. This will become even more important once we support custom viewers.
