The functionality to add nodes on link dragging allows to quickly extend a node tree with a string of operations. Due to the fact that this functionality is a modal operator it would be possible to add additional keyboard inputs before the mouse button is let go, to quickly terminate the operation and pick a certain nodes with a shortcut, instead of typing in the name in the search bar after letting go.
This extended functionality would drastically increase workflow efficiency in the cases of a few, commonly used nodes.
Which nodes that includes and how the selection adapts to the context of the dragged link (editor/socket type, in/out link) needs to be figured out/discussed in this task.
Proposed included nodes and shortcuts:
Input
1 : Value
2 : Color
3 : Vector
Link Type: Any (Node version/settings according to the matching datatype)
W: Switch
Y: Reroute (visual representation of a junction and R is reserved)
Link Type: Geometry
J: Join Geometry
P: Set Position
Link Type: Shader
X: Mix Shader
A: Add Shader
Link Type: Float/Vec/Vec2/Col/Int/Bool (Node version/settings according to the matching datatype)
X: Mix (Ideally there would also be nodes for at least vector and float)
A: Add
S: Subtract
F: Multiply (F for factor)
D: Divide
C: Curve
R: Map Range
G: Color Ramp (G for gradient (?))
I: Invert
Separate/Combine Nodes
Using the context sensitivity of the shortcuts, the different separate/combine could elegantly be solved with the keys 1, 2, 3.
Examples:
Dragging from a float output and pressing 3 would add a Combine XYZ Node.
Dragging from a float input and pressing 2 would add a Separate RGB Node.
Dragging from a vector output and pressing 1 would add a Separate XYZ Node.
↓ Key \ Socket → | Float In | Float Out | RGB In | RGB Out | XYZ In | XYZ Out |
1 | Value | / | Com. RGB | Sep. RGB | Com. XYZ | Sep. XYZ |
2 | Sep. RGB | Com. RGB | RGB | / | RGB | / |
3 | Sep. XYZ | Com. XYZ | Vector | / | Vector | / |
*Note: This might look confusing, but my hope is that it is intuitive, when used.*
Notes
The shortcuts should be sensible with the name, but that leads to collisions quite quickly.
Many more useful rules would be possible, but I would keep it to a relatively small and manageable amount for now. The more get added, the muddier and subjective it gets which nodes should be included.
In a perfect scenario this would even be customizable by the user, but for now it would need to be hardcoded.
Some of these nodes are not yet available in every node editor and should be following the implementation of this feature. Unifying the node editors to allow the same workflow/copying nodes/sharing nodegroups is a separate discussion, but should be addressed in a sensible scope for this task.