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.
2 Likes
that sounds interesting
Does it require being able to select a node slot? Connecting distant nodes without dragging a long noodle might be useful for regular nodes too.
I could be something on the context menu when you hover the socket. And yes I would implement for all node editors.
Hiding long connections could be useful for de-cluttering node trees.
Maybe a viewing mode, similar to viewport’s “x-ray” (z) in which all connections are temporarily visible could help with debugging.
3 Likes
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
Afaik it will come back in 3.1
See topic here
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.
3 Likes
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.
2 Likes
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.
9 Likes
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 
1 Like
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.
I love the use of WiFi or wireless signal icon here.
2 Likes
Hi,
here are two possible examples of workflows for hidden wires, these are concepts in grasshopper which is a open source node script system for rhino cad.
and in the video at minute 11:00 hidden wires.
These are plugins from users who are confronted with large node groups.
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.
Is it possible to have something like const local variables, that could be set once per function call, and trigger an error when they aren’t?
With more and more complicated node system, it gets closer and closer to “real programming”.
IMO introducing simplest fundamental programming concepts, and using conventional naming for things, in the long run is way less confusing, than inventing unique terminology and unique concepts.
Taking some ideas from this thread, I have visually updated the instantiated nodes proposal. In this example the instantiated node is Distribute Points on Faces, as you can see the connections of one node are indicated in the other and the values are identical. Selecting either node should highlight the frame of both. As there are two instances I have indicated it with the number 2, and because it should be possible to make the nodes unique I have also added a dropdown menu.
As I have commented previously, this already acts as portal, but instantiating groups could act as a collector and at the same time process information.
9 Likes
The idea of hidden named noodles might be easier to read. Without selecting anything, one can see where portals come from, and where they are used.
I thought about portal-noodles for a while. My main concern is that current portals are indistinguishable, until a connected node is selected. One would have to go through all portals to get an idea of whats going on.
Thinking about it, it appears to me that it might be like someone looking for a snack … but he cannot find the fridge, because he walks around with a microscope.
As a user, I like much the idea of named portals.
1 Like
Elegant, familiar, partially working - could be improved to be a global workflow and viola.
1 Like
In case the (Noodleless?) Wireless Portal will get implemented, how about when selecting either Receiver or Transmitter, the other one would automatically get highlighted?
Like, always be highlighted in pair so you always see the link.
TBD whether to make a special type of highlight, or just keep the current one.
But I wouldn’t want this for the alternative. (dimmed/hidden noodles)
1 Like
Someone raised this idea (or something like it) earlier in the thread, but I like the idea of there being an option in the overlay panel that when checked or unchecked would automatically add back in the noodle connections that portals would remove. Toggling the option again would go back to the elimination of the noodle lines or line segments. That way, if for some reason you wanted to quickly bring back the mess of noodles and the corresponding ability to trace one node to another visually, you would be able to do so.
8 Likes