General remarks on node groups
- Build up complex effects out of small elementary parts
– Generic diffuse/specular/environment shader from different bsdf nodes, to be used as a “classic” material
– Particle emitters from basic components, such as create new particles -> distribute on mesh surface -> initialize velocity from normals, etc. Combine these in a single node group and you have a complete particle emitter asset.
– Procedural objects with modifier nodes, e.g. a “window” asset from simple base shapes and user settings like dimensions, number of panes, frame thickness, and of course different material slots for all the parts
The advantage of generating such complex effects from simple components instead of adding them as a new node type is customization: You can take an existing shader/particle effect/object, make a copy of it and then tweak any internal part to make a new one. All this can be done by artists or TDs, without having to write C code and either use their own Blender builds or get a patch accepted into trunk.
- Interface reduction
Often a node can be quite cumbersome to set up, especially if it is a complex node group with lots of different user options. Reducing the interface of such a node or node tree is a good way to create a usable tool by only exposing those settings that artists need frequent access to. Any setting that is not exposed will just use a default constant value internally.
Problems with editing node groups
1. Only a single level of node group depth
2. Only a single node group can be edited at a time
3. Input/Output columns in display
Make a usable “frame” node
There is a new node type called “Frame” in the Layout category that provides functionality expected from node groups (the naming should be changed as well, one suggestion was “Tray”). The current implementation is still experimental, but with a little bit of work it can be a great feature.
The basic idea is to use this as a kind of local grouping helper. Any node (including other “frame” nodes, groups, etc.) can be attached to it, much like object’s parent/child attachment. Moving a frame node also moves all attached nodes. They can be linked to nodes outside the frame. Hierarchies of frame nodes can be created as well.
Unlike “real” node groups these frames can not be instantiated (shared), but they could allow simple duplication of all attached nodes. Since this is a very common use case for group nodes they seem to be a good replacement for local grouping of nodes.
Here’s a list of proposed additional features:
- Clear indication of attachment (currently not visible)
- Beside explicit operators for attaching/detaching nodes to frames: Moving nodes outside of a frame detaches them.
- Moving nodes into a frame while pressing a modifier key attaches them to the frame (currently always attaches automatically).
- Frames can be locked, i.e. no attached nodes can be moved, all buttons are inaccessible, no linking, etc. This way the frame can be handled as a fixed, local group and makes editing easier.
- Frames can be collapsed, to free space in the layout. This has some design challenges though, like how to deal with links to/from the attached nodes.
- Standard operators for duplication and deleting work both for a selected frame node alone as well as the frame plus all attached nodes (using a modifier key)
- New operator for “make frame around nodes”, similar to current “make group from selected nodes”. Ungrouping simply means deleting the frame node (see above).
Not included here are all sorts of UI display improvements, such as easier resizeable borders, custom color schemes and so on.
Edit node groups as separate trees
Reusable, standalone node groups would be edited just like any standard node tree would be. When “opening” a node group the editor display will switch to the internal node tree, instead of pretending to display a specific instance of that group in its parent tree (which is in fact just the shared node tree). This way the editing of nested node groups works in a consistent way across all possible levels.
No more nodetree/edittree distinction in the node space struct is required, there’s just a single active nodetree. The node editor window can keep a history of node paths in order to allow a web-browser-like behavior:
- Opening a node group pushes a node path onto the history stack, before switching the node tree over to the group internals. (“Follow a link” in web browsing terms)
- Closing the node group means popping a node path from the history and go back to the previous tree.
This behavior may not be quite as immediate as the tab-tab edit mode currently possible, but it seems that this a tradeoff between flexibility and simplicity. For simple grouping the frame node type described above would be used instead. Node groups on the other hand will become the choice for long-term reusable node assets.
It may be a good idea to actually implement these nodes as a completely new node type “Asset”, instead of remodeling the existing Group node type. This way the usability can be tested and if successful the Group node type can be removed at some later date.
Detach interface sockets from columns
- It reduces clutter in the layout. Interface nodes can be placed by the user just like any other node, thereby cleaning up the layout and making it much easier to understand. Inputs/outputs can be closer to the internal nodes that make use of them.
- No more automatic unintended movement when the bounding box changes. Less problems with unintentional inserting of nodes in links.
- Less space wasted on interface settings. Once the group socket has been set up properly the node can be collapsed and only takes a small amount of space.
- How to set up the order of inputs/outputs?
The column stacks make this quite intuitive, so i suggest to keep socket display there, but just display names. Changing the ordering there should use drag&drop instead of buttons (much easier + also saves space).
- Only one node for each input/output, having multiple nodes for the same socket would be too confusing. Using the same input in different places can still lead to long links, but it’s much more controllable then and is at least not worse than the current system.
- It would be nice to still have some visual indication of which tree socket in the column associates to which internal node. This is not as important as it may seem at first, since there is no real functional connection between the order of sockets in the columns and their nodes. However, some sort of highlighting indicator when selecting the node or the column item would make it easier to recognize them quickly.
Generating top-level interfaces from node trees
After implementing the first two of the features mentioned above (interface proxy nodes and browser-like tree editing), i’ve made a little video tour to show them in action: