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.
The more I think about this, the more confusion it causes naming them portals.
To me, adding hidden noodles is a no brainer. The majority of users won’t have a need for them with simple node trees and the users who do use them will be glad of the functionality.
Similar to muting noodles - it’s just not functionality that the average user will bother with.
Calling them portals makes it seem like some big workflow feature that I think muddies the discussion because they’re not really a huge thing. It’s just a nice to have for more advanced users.
Portals could be something else entirely that actually offers a novel workflow. I’ve not really thought about what that could be but I know there have been proposals in the past along those lines.
Assuming hidden noodles aren’t going to break some other functionality, I’d just chuck them in and continue the portal discussion more along the lines of a deeper workflow change.
I assumed the ‘portal’ word was just used as a placeholder for this discussion. I agree it’s a terrible name for such a simple feature. Also because ‘portal rendering’ is a much used technique in 3d game engines.
It’s good to say this out loud, so whatever gets implemented doesn’t get the actual name ‘portal’ in a release
You can hover only one socket at a time. But it is still possible.
Two steps. One operator to remember a source socket (cursor hover source) and another operator to connect the source socket to a target socket (cursor hover target).
If there are ‘portals’, probably a ‘portal to target’ operator would be useful, which connects source node to target node in portal mode.
(Get/Set)