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.
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.
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
I personally like hidden wires a lot.
I like that they appear when a node at each end is selected.
I would prefer to see them actually hidden when they’re set to portal, right now they show up the same as a regular dimmed noodle.
[portal top, dimmed bottom]
Something like this might be more readable if the noodles are exposed when clicking one of the ajoining nodes.
For people wondering why it’s a useful thing to have, in larger setups where everything is entirely generated in the node tree you might want to pull off the controls into one frame rather than running around the whole tree. You could put it into a group but that’s not often convenient if you still want to tweak settings.
This one only has a few variables (and the portals only dim instead of actually hiding) but you can see how this makes the node tree much more visually clear by being able to toggle those long noodles:
I think the problem of collecting all properties in the left side of a tree can have different solution. I see that such properties are like global variables of the tree and it would be logically to remove them from tree space and put them into property panel of the tree. In this case you should not always navigate to those nodes but simply open property panel and change what ever property you want. The connection to tree property can be performed via TreePropertiesInput node. Or it can be done via drivers #NameOfProperty.
No nodes no problems.))
I had this proposal a year ago - Geometry Nodes - #25 by Random
Hello, a long time ago I made one of the proposals indicated above
Portals for nodes
, and shortly after I made another with the same objective but that I consider more versatile.
Instantiate nodes and improve node group editing.
As the title itself says, the proposal consists of instantiating any node, and when selecting an instance, the rest of the nodes of the same instance are highlighted. The Portal concept would be added when instantiating groups of nodes, since they could receive attributes from different parts of the tree, acting as a collector. If an input socket of one of the groups is busy it should be indicated or blocked.
The advantage over the portal is that it can process the collected attributes. If all the inputs came from the same site, and had their direct equivalent output, it would act as a simple portal, but being able to collect attributes from different sites and process them before expelling them, I think it can give much more play.
Mh … to be direct I do have mixed feelings about portals.
I like some ideas, like using portals to feed a Join Geometry node.
I see that it could help to avoid a visual spaghetti mess with many crossing noodles. Would it be an improvement if visible spaghetti gets substituted by invisible spaghetti?
Imo, node artists do have responsibility on how they shape their node tree. I mean, a messy node artist could weave a big scary knot, with or without portals.
The way portals are drawn in the viewport might be improved. It would help if eyes could more easily recognize portals on smaller Node Editor’s zoom levels.
Big node trees are always problematic, and there are tons of memes about it. I agree with the concept of the portal links as proposed, they indeed help cleanup the tree (not the readability probably). One think that I would like if going the route of the portal links, would be the ability to copy a portal link into another socket avoiding dragging the original socket that can be miles away.
As a note, I do understand that getter/setters nodes would add more complexity, to the system due to how the tree is evaluated, for example the same position node + math nodes could have different meanings according to each socket its connect, and would be hard to translate the result of getter/setter (just check the Simon Thommes latest video https://youtu.be/53VkGwN9GBo?t=1266 the bottom left “group” for what I’m meaning).
Maybe it has already been proposed here, I scanned this thread and I think I didn’t see it yet, but…
Something that would be very useful to have, in addition to portal links, is ‘Bundler nodes’.
Where you can connect multiple wires to the ‘Input bundler’, which then is connected via a single noodle (or even portal link) to an 'Output bundler" where you get all the bundled nodes out again as sockets.
crude mockup:
This could rather declutter the circuitboard-like look of some node trees.
Portals already kind of exist. It might technically be a bug but disabling sockets severs the noodle between nodes but it does not actually remove the connection itself. I made this with two lines of python so there is not much to it actually.
This issue has been successfully solved by Nuke a long time ago with dot node. This more obvious there’s something hidden, and you can “offset” the node to avoid it’s link cross the graph. Of course, link appears when the dot node is selected
That’s pretty much a group but with its guts exposed.
I am pretty fond of the concept of hiding some links. @Erindale’s mockup looks good. And the usability shown in the video in the first post with some sort of mouse/keyboard combination is a must to hide the wires. In another nodes software I use, to hide the wire, there’s always the need to right-click and select the option from a nest menu, which significantly slows down the workflow.
Additionally, there could be a special portal connection as well, the connects things wirelessly. I believe Sverchok has that and works fairly well.
The concept of storing attribute within a geometry already existed and was called “Store named attribute” / “Input Named Attribute” (Get/Set)
The concept was more consistent than this one IMO, as stored attributes were visible in the spreadsheet and can be transferred from modifiers to modifiers
II think you misunderstand what I mean, because it has nothing to do with a group. A group does stuff with it’s inputs and then generates an output. This just bundles multiple noodles together.
The idea is that you can replace tracing a bunch of noodles together with just one noodle.
But this isn’t meant (only) for attributes. It’s meant to bundle noodles.
Sometimes you need the same set of 5 inputs in multiple places in your tree, which leads to ‘lanes’ of noodles snaking around your tree.
For group inputs you can just add an extra group-input node, but for calculated values inside your tree something like this could imho be useful.
I think i’s the same idea as a portal node, but with a single noodle between the input & output portal. Combine it with portal links and you have the same as a portal node.
I guess I don’t really like the idea of a completely broken/invisible connection. That existed with the named attributes workflow from 2.93 and it lead imho to very hard to follow nodetrees.
I’m for Portal Nodes (instead of Portal Links).
Conceptually, I see them work similar to Frames (CTRL+J).
You develop some level of functionality (deformation), and you’re happy with it.
On top of that, you want to add another functionality (selective material change).
On top of that, you want selective point instances.
… you get the point…
You can pass the geometry through a portal, to continue your development in another section of the tree, so that you don’t clutter everything in one place.
You can even add a Frame on a whole [Portal In - Portal Out] section, to make it super clear how that cluster does a specific thing.
(Get/Set)