Portal Links Exploration

Archive Geometry Nodes
1

The goal of this thread is to determine if and how portals in Blender’s node editor can help to improve the node editing experience.

What is a portal?

Portals allow sending data between different places in a node group without having a visible link. The underlying assumption is that some links, while necessary for the functionality, are not important enough to be drawn all the time. The problem with some links is that they intersect many other links or require multiple reroute nodes. That leads to unreadable node groups or additional work for setting up reroutes respectively.

This exploration is only concerned with portals that work within one node group. Mechanisms to send data between different node groups or objects are not discussed.

Previous Work

The idea of portals is not new. Below I collected a few examples where portals have been proposed or implemented in the Blender community before.

Types of Portals

Proposals for portals generally fall into one of two categories: portal nodes or portal links.
Most proposals focus on Portal Nodes. That means that there are usually two new node types. One that represents the input to a portal and one that represents the output. They are linked together by some name or internal identifier. Often, multiple portal outputs can correspond to one portal input.
Another approach are Portal Links. In this case no new nodes are required, because a link itself can become a portal.

Both approaches have their advantages and disadvantages:

  • Portal nodes take up more space but can be easier to see when zoomed out.
  • Portal nodes usually have a name embedded directly into the nodes which makes labeling a portal easier.
  • Portal links can be built-in to Blender and can work with all node systems out of the box.
  • Portal links don’t require the use of names. Custom labels for links or output sockets could be added separately.
  • Portal links may fit more naturally into existing workflows in Blender.

Portal Links Prototype

Proposals and implementations for portal nodes exist for a while already, but I haven’t seen portal links in the context of Blender before. Therefore this section describes a prototype for portal links that can be downloaded on the build-bot.

The prototype contains the following features:

  • Every link can be turned into a portal. For that hold down V and right click and drag across a link (similar to how links are cut or reroutes are inserted).
  • Portal links are not completely transparent but almost. They are still visible a little bit without being distracting when they cross other links and nodes.
  • Portal links display an indicator at both ends.
  • Portal links that are connected to a selected node become more visible. So to see all portal links, just select everything.
  • Portal links can become normal links again by first making them visible (by selecting a connected node) and then using the same shortcut as before.
  • Portal links can be relinked like any other link.

There are of course many ways in which the prototype can be improved. Feedback for that is welcome, but feedback on the workflow topic below would be even better for now.

Workflow Exploration

Having portals in Blender may require some rethinking of existing workflows for keeping node groups clean. While portals can easily be added to an existing file, it may be more interesting to build a new project with portals in mind to see if it would affect the way node groups are laid out.

Uncontrolled use of portals can also have negative consequences. In extreme cases, when most links are portals, node groups can become less readable again. Portals also have the tendency to make it harder to see the dependencies between nodes. Showing portal links of selected nodes alleviates the problem a bit, because nodes need to be selected to be able to move them. So one will always see all dependencies when moving one or more nodes.

Ideally, we would find some kind of guideline or rule of thumb when portals should be used and when not. The rule may differ for different node group types (shading, geometry, …). I challenge everyone reading this to try to come up with a rule for using portals that generally improves the experience when building the node group while keeping it readable.

Workflow Ideas

This section provides a few rules that could be used as a starting point for the challenge mentioned above.

No Portals

Maybe, in the end we’ll notice that all portals are bad and they should not be used. In this case we shouldn’t add portals to Blender of course.

No Intersecting Links

Another possible rule would be to use portals whenever links intersect. This would make the node group look clean, but probably results in worse readability. Also, often it would be arbitrary which link should become portal.

No Attribute Field Links

This rule only applies to geometry nodes. The idea is to always use portals instead of normal links when connecting attribute field outputs to something. This can help break up parts of the node group. It may also be a good alternative to using named attributes to avoid long links.

attribute_field_sockets
attribute_field_sockets787×400 54.1 KB

Portals to Join Geometry

Often geometry node groups have Join Geometry nodes in the end that just combine all the different geometries generated in the node group. A possible rule could be use portals for all the links to the Join Geometry node.

join_portals
join_portals1073×491 377 KB

29 Likes
2
3

From a first look I have some comments.

  • Using the mouse over the wires to enable/disable the feature us counter intuitive, you will have to remember the exact mouse movement / button combination and it’s not something obvious or user friendly, specially being such an important feature

  • There is no indication of what is connected to what, except some faded wires, which in return is very similar to not having portals, so the visual noise is still there

  • This could be easily solved in the same way is solved in programming, with variables, use a get/set node pack and just set the output to a variable, get the output to a variable, that’s it.

My personal conclusion is that while this can be useful, and it has been said here that it can be improved, a get/set node and internal variables (internal named attributes if you prefer) are a much better solution IMHO

10 Likes
4

I think there is also another problem which Portal links could solve. Some times there is need in linking some socket located in one side of a tree with socket in another side. In case if tree is huge you have to scroll down and try to click on the socket and then drag the link and release the mouse nearby another socket. Some times you have to make several attempts.))
There is another entity in Sverchok named quick link.
quick link
Probably this conception can be mixin somehow with Portal links.

5 Likes
5

I think the idea of giving names to intermediate values in the node group is conceptually separate from the idea of portals. Portals can exist without names and names can exist without portals. Both can be useful individually and even more so together. What is shown in the video by @Random is essentially names without portals. We could have the same in Blender.

For the time being we can just do something like in the image below. This is obviously not as great as a built-in solution for naming intermediate values, but it’s a start:

image
image738×353 30.2 KB

8 Likes
6

But that example, wouldn’t that be the same as having a get/set node? (sorry to insist, I’m trying to understand the difference here)

You just can create a get node and duplicate where ever you need it, no need to extend wires and then convert them to portals.

That example could be an intermediate solution, you can create attributes in the input node and then extend a named portal, then connect that named portal to whatever socket you want in your tree.

As I said I’m not against portals, just don’t see the benefit over internal named attributes with get/set nodes.

3 Likes
7

The benefit is that you don’t need to specify a name. I think the proposal makes the pros and cons of both very clear. The portal links can be used to quickly clean up a node tree visually, without having to come up with custom identifiers for every link.

8

Having Set nodes that write to some local state could potentially be confusing, because you couldn’t copy the Set node to write to the same variable in multiple places.

As I said I’m not against portals, just don’t see the benefit over internal named attributes with get/set nodes.

For me the benefit is that these portals (combined with the ability to label intermediate values, e.g. with improved reroute nodes) are conceptually simpler, easier to integrate in all existing and future node trees, while still solving the same problem. Also note that we are not talking about “geometry attributes” here (not sure if you meant that with “named attributes”).

Just like in Sverchok we could provide a way to create a (portal) link to a labeled intermediate value without having to create the long link manually.

3 Likes
9

I think it would be nice if it will be possible to call an operator (by pressing hot key) while dragging of a link was started. Then the operator can take information about a socket from the started link and connect it to whatever what user wants.

10

I made a quick design mockup. The brighter green dot means its the end of the portal link. Maybe you could press the green dot for the portal to be turned back into a normal wire. Also I put portal links in the node editor overlay dropdown menu so you could turn the links on and off as an overlay. :grin:

my mockup
my mockup1912×880 59.3 KB

11

The “portal links” idea sounds pretty good to me, except it doesn’t avoid the user having to link nodes that are far apart in the first place. “Portal nodes” simplify this process a bit, and are a little more informative too : I assume they would show the connected socket’s name instead of only revealing that there’s a link but still needing the user to scroll all the way back to see where the link attaches.
Of course portal nodes would be a little more involved to set up : in essence they would work similarly to “group input” nodes.

3 Likes
12

This is interesting, if I picture them in my mind like a node, instead like a reroute node (the reroute is smaller and could create more visual noise IMHO making it more difficult to read) it may work nearly as variables, but instead of variables are just that, portals.

Regarding the set node, well, you can down the tree overwrite a variable (let’s not call them attribute because of what you say).

So for example lets say I have a variable “my_pos” then I use the set node to store the initial position of an object, then I use a get node to deploy that position into a transform node, then I after that I sue a set node to store new positions, in the same variable but after that transform node, and then I use a get node to deploy those positions to an set position node.
In that case I’ve been using all the way the same variable “my_pos” but it stores different values at different moments in the node tree.

However this is probably a different conversation now that I being to understand what you mean with the portals, and yes, it can be useful, an different to variables and/or named attributes.

13

Probably pressing on the portal socket can shift current tree view to opposite socket similar like pressing Del button on numpad can shift view to selected object.

1 Like
14

yes that sounds more helpful! far better idea :brain: :grinning_face_with_smiling_eyes:

15

Conceptually, in this prototype I see this as hidden links/wires rather than portals. For portals, I’d imagine that there would be additional UI tools to aid users making connections. E.g. a popup of some sort that lists the portal links/sockets.

16

I like the practicality of this. An alternative solution idea I liked very much is one someone proposed a couple of months ago somewehere (I can’t find it unfortunately). It consisted essentially of “instancing” nodes. So for example you have a node somewhere in your nodetree receiving some connections, you alt+d it and you have an instance of that node that’s already receiving those connections wirelesly and you can use it’s outputs in another part of the tree. It could also work with reroute’s so if you plug something to a reroute, instance the reroute somewhere else in the three you have essentially a portal link.

2 Likes
17

These are all conceptually separate issues for me, but we can address them soonish as well. Just talked to Hans and we’ll try to revive D8286 and maybe add the ability to link to a named reroute. More updates on that later.

I think it would be nice of the end of a portal would not be larger than a socket, because otherwise you’d get overlapping elements when sockets that are next to each other have portal links.

Yeah that won’t really work in geometry nodes/shader or compositing nodes. That makes sense in a game engine where you have events and actions that happen on these events, but not really in Blender right now.

Interesting idea, but I fail to see the benefit of this right now. It seems to add quite a bit additional complexity.

In general I’d like to see some more feedback about when you’d use (potentially named) portals in a concrete node group. I still think it would be good to find a teachable rule of thumb for when portals should be used. This can also help make the design more clear and useful.

3 Likes
18

I can’t think of when I would want to use portal links in my own workflow. The wires are already dimmed if both of the connections are off screen so it would only be marginally more clean, but it would be difficult to visually understand how someone’s graph is working if they’re using lots of portal links. I’m imagining having to select each node one by one to see what it’s actually connected to…

I would love to see portal nodes though! Being able to pop in a value on one side of the graph and use it on the other side without having to drag a super long connection between the two would be extremely helpful. It would also be easier to understand because they would be clearly labeled and, like any other node, could be colored or renamed to further clarify what parts of the graph are connected.

7 Likes
19

I think the this style make me confuse: I don’t kown which socket connect to which. It is hard to read.
One way to clear the connection is to know the true name of the node. Not the current complex label overwrite system. The label should be a tips, darker and cleaner, not the title of the node. and the title should be more big so that we can easily read what we are doing (Also point out the origin type of the node)
With these changes , a bigger size portal node with label should be useful

20

Maybe we could have some magic algorithom generating tidy wire routes like Circuit boards？

1 Like