chaiNNer
chaiNNer copied to clipboard
joeyballentine
Simple variable node aka portal node
A simple node that needs to be given a name inside it, there is an input and an output (only one of them is required). Then if you set a value on input, you can create the same node with the same name and the value will be "copy" there. This way you can reuse values already obtained in one part of the canvas and not create spaghetti nodes.
Might be possible now that we have a dynamic type system. But I'm not 100% sure if this is still possible. @RunDevelopment would have to comment on if it's possible to determine the type of something like this for validation purposes
I may be misunderstanding, but I'm not sure of the purpose of this? It sounds like creating two nodes and two connections in place of one connection.
I think they just want to be able to separate stuff rather than having "spaghetti" of connections everywhere. Idk, might help make things look clearer. I've had this same idea before, but I wanted to call them "portals"
@joeyballentine Yes, I wanted to named the topic portals, but I thought it was not too suitable a name. @theflyingzamboni wait a couple of minutes i will draw an example.
Okay, it is what I thought then. Seems like a lot of extra node clutter to me, but if some people prefer their chains that way, maybe it's something we'll be able to implement.
@theflyingzamboni I got distracted and lost the real idea I wanted to show. Sorry.
But the meaning is this:
(I've been experimenting with the code so the nodes don't look fully right)
Only in the real example the canvas is large and doesn't fit on the screen.
Yeah, that's what I thought you meant. Seems worse to me tbh, cluttering up the canvas with more nodes, but I'm not necessarily against the option if we can get it and the typing to work.
For me, more nodes are better than when the lines intersect, reaching a state where it is not clear where what.
I think adding this is a bad idea. There are two reasons for this:
(1) Complex implementation.
These portals are equivalent to simple connections. However, they are a lot more complex. If we send those chains as is to the backend, we would even have to make the executor aware of these special nodes. If we essentially "desugar" those nodes into simple connections before executing the chain, then we'd have to resolve all portal before execution (more doable). There's also the problem that portal literally redefine what a connection is. So we'd to change all code that looks at connections (which is a good chunk of ChaiNNer).
(2) Complex usage.
Let's assume that we implemented it. Is it actually beneficial? I would say: no. Sure, complex chains might appear less cluttered, but they are no less complex. You simply hid the complexity using more nodes. This makes it a lot harder to understand chains. Right now, we can see all nodes connected to a specific node, but this won't be the case with portals. But it's actually even worse than that. You need to add nodes to use portal, so you actually increased the complexity of the chain.
To summaries: I am against this feature because it will be complex to implement and because the feature itself isn't beneficial.
However, @0x4E69676874466F78 is right that intersecting connections are a pain. This is a real problem, but I think that portal are not the solution. Instead of hiding connections, ChaiNNer should have tools to automatically re-arrange nodes in a way that are as few intersecting connections as possible.
I compare ChaiNNer often with programming languages (because it is one). ChaiNNer is currently missing a formatter. No programmer of textual programming likes the task of formatting their code by hand, yet we expect ChaiNNer's users to beautify their chains themselves.
This is somewhat unrelated to the issue, but I still wanted to share my thoughts. I kinda want to object to portals on principle. ChaiNNer is a graph-based visual programming language. However, portal are a text-based feature because the node/identifier of the portal determines its connected value. This completely goes against the visual flow-chart-like nature of ChaiNNer's chains. I think that we should completely embrace the graph-based nature of ChaiNNer.
You can extrude (push out) the lines around the nodes, but this will not solve all the problems. Someday, when I start making my node UI library, I will fork chaiNNer and try to show my version.
this will not solve all the problems
Could you explain what problems aren't solved?
It is not always possible to create a graph so that the lines of its nodes do not intersect.
Well, yes. Not all graphs are planar, but that is just in the nature of graphs. I don't think that this is a huge problem as long as we can minimize the number of intersections.
Just adding to this It'd be great if I could draw my own noodles, I use a ton of pass throughs atm to get minor things moved out of the way.
@Eagle1337 would https://github.com/chaiNNer-org/chaiNNer/pull/2548 accomplish what you're looking for?