In the current node editor workflow there is no good way of moving nodes between different node trees. Nodes can be duplicated in a node tree, but not easily transferred to a different tree data block.
While it would have been a nice feature in earlier Blender versions, the lack of it was not really a showstopper, since all node editing basically worked in the same node tree. The only exception would be editing node groups, but inputs and outputs were generated fully automatic (and pretty much useless), so it was possible to just destroy and recreate a group to include nodes from the parent node tree (even though this means piling up old unused group data blocks). Now the interface for node groups is much more controllable (custom socket names, internal links) at the expense of requiring some more work by the user, so simply creating a new node group data block every time you want to add nodes seems stupid. A good workflow for moving nodes between a parent tree and node groups becomes imperative, even more so when thinking about the future (groups inside groups, more customizable interfaces). My first attempt at creating such a feature was to implement copy/paste operators, similar to what you find in other software for duplicating/moving data between different parts of the program (code review here [1]). While it works for simple cases, there are a number of problems that are not easily solved: * Animation data would have to be extracted for just the copied nodes, then stored in an "clipboard" buffer and inserted+remapped in a different ID block later. Could work in principle, but might have ugly corner cases and no precedence in Blender so far. * Pointers in the node data would have to make sure the user count is handled correctly (clipboard should not increase user count), and must check for existing data blocks on insertion into other trees. It seems that this approach has too many risks of losing data and is generally not "The Blender Way (tm)". So here is my suggestion for an improved method that follows existing patterns: 1) For inserting into existing groups: extension of the "make group" operator (ctrl+g) The operator would show a selection popup like the parenting operator, with options depending on the type of the active node (last selected): * "Make new group" -> regular operator, creates new group type with all selected nodes inside. Currently still prohibits groups inside groups, but that is technically possible now, so should be allowed. * If active node is a group: "Add to group" -> adds all other selected nodes into the group (exception: one of the selected nodes is of same group type as active node (or contains it on deeper level). Recursive grouping is still impossible.) 2) For extracting from an existing group: Add a "separate from group" operator (p ?) Works similar to separating vertices/edges/faces from mesh (p). This will move the selected nodes from the currently edited node group to the parent tree. This could also have two options in a selection popup if needed: * "Copy" makes a copy of the nodes in the parent tree, but keeps the original group intact. Note that the "ungroup" operator works similarly: it makes a copy of all nodes in the group and removes the instance, but does not actually change the node group itself. * "Separate" will remove them from the node group. Any connection to unselected nodes is removed! * "Separate with interface" will remove from the node group and add new interface sockets for broken links. These can then be fine-tuned afterward with meaningful names, etc. The introduction of popup selections to specify operator modes is an additional step in the workflow, but since these operators are not executed very frequently i think they are justified. They help to keep the number of direct keyboard shortcuts needed to a minimum. After executing any of these operators the editor should switch to the "target" node tree (where copied nodes are placed) to allow quick placement of those nodes. Note that this method still does not provide a good way of directly moving nodes between unrelated node tree data blocks, only between node groups and respective parent trees. I think this is an acceptable limitation as sharing nodes between different trees would usually make use of node groups anyway. If necessary an intermediate group could even be used as a "clipboard" for transferring nodes this way - clumsy, but avoids the problems of direct copy/paste. Let me know what you think. Cheers, Lukas [1] http://codereview.appspot.com/6249060/ _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers