Reroute node 'tele' operator
Open, NormalPublic


This patch intends to help manage and organize complex node layouts/setups in the in the node editor view.. To see it in action: Select one or more reroute nodes and hit 'Ctrl D'; you will see that they have each split into a pair of reroute nodes that can be relocated independently; think of them as an 'in' portal and an 'out' portal.
Thus you could separate out logically independent sections of your node setup.. the screenshot shows an example, a very crude one though.

The way this works internally is simply by creating an extra reroute node to serve as the input portal, keeping it linked to the (existing) output portal, and skipping the drawing of the intermediate link.

This is very much a work in progress.. some immediate things that I can improve upon:
a) make this toggleable in some sense if possible
b) Use a matching highlight color for node pairs, to clearly indicate which in-portal corresponds to which out-portal.

On a more long term perspective, I would like to extend this concept to a sort of a Bus-node: any socket output(s) can be plugged into it, and any Bus output can be quickly instanced from any other location in the entire view.



From what I can tell this is a kind of split tool,

Currently you can duplicate the re-route, place it near-by then Ctrl+Drag to cut the connection.
It sounds complicated. but if this is not something dont so often... it may be acceptable.

If we are to make this functionality possible, it could be done a bit like the mesh rip tool, where you can drag away one side of the connection. (based on the cursor location)

However before spending more time on this. I would like to hear from people who use the node editor a lot, to see if this is an area that really needs workflow additions like this.

@Sebastian Koenig (sebastian_k), @Greg Zaal (gregzaal)?

>> Currently you can duplicate the re-route, place it near-by then Ctrl+Drag to cut the connection.
Yes, the patch was just a quick demo hack, from my very early Blender development days :)

I would also like to get feedback from others, particularly about the much wider 'Bus node' idea which I had briefly mentioned at the end of my original post.
Just to outline a potential use-case for the Bus node:
Typically, the outputs from source nodes (image, renderlayer) etc. may be needed again towards the end of the node setup, to mix/overlay etc. with a composited version. Currently, connecting distant sockets across the entire setup (often overlapping other nodes) may look cluttered; and is not 'modular' in some sense.

A 'bus' node will have input/output sockets called 'channels'; and the channels of all bus node instances are wired to each other (internally, hidden from UI), so that the inputs get replicated at the outputs of all other bus nodes. Of course, the user may change the number of channels needed, and suitably label them.

One benefit of this may be that a large node setup can be conveniently broken into smaller 'modules'; each of them would directly read/write from/to bus nodes. Thus each module can be independently moved, saved and shared.

Just to clarify how I understand this - it's a sort of invisible link? So you'd have a pair of reroute nodes, one of them the input and one the output - plug something into one and the same data can be outputted from the other - meaning something like this is possible:

If that's what we're talking about, then yes, I think this might be useful. But it's a hack solution to a messy node tree, and can potentially make it far more confusing. I would definitely suggest some strong visual cues to indicate which portals are pairs, and that they're not just regular reroute nodes. Some off-hand suggestions for that:

  • Use a different shape for the portal node - so that we know it's not a regular reroute node (e.g. square, semi-circle...).
  • Use a unique colour for each pair to distinguish which portals belong together.
  • Visualize the connection when the user hovers the mouse over one of the portals (e.g. dotted line)

But although I think this might be cool, I'm not sure it's really feasible.