Linking nodes across node trees

[DolphinDream]

Is there a way to link nodes from one node tree to another? If not, would a WiFi MK2 be a good extension for such functionality ?

[Durman]

There is such functionality and for now it calls monads.

[DolphinDream]

@Durman you’re funny :)
Anyway.. sometimes I want to create different node trees to dedicate to specific parts of the rendering.. that i could control separately (update, visibility etc). So, I guess you’re saying that if I want to propagate a value from a node in a node-tree to another node in another node tree.. that functionality you say does not exist... yet.

[Durman]

Well, monad actually creates another tree and you can pass values to this tree via group node sockets. It feats to your description. But monad tree can't have output nodes and in this way its tree can't be used independently.

For this reason I'm thinking about adding possibility to have output nodes to node groups (which should replace monads). So probably you are asking about node groups functionality.

[Durman]

In general idea of passing values between base trees is bad. And wifi node conception I also consider as bad. They hide links and make it more difficult to find dependencies. If you have big tree (hundreds of nodes) you can never find all places where wifi nodes was used. So it is losing of control and brings more harm than benefits. And I'm even not talking about how it should overcomplicate update system.

[rendetto]

I while ago I've asked zeffii for such feature of "WiFi" node
https://blenderartists.org/t/wip-sverchok-parametric-nodes-for-architects/557250/2460?u=rendetto

My first thought was the ability to pass simple data and objects among lighter node structures which I can switch on or off.
What I miss a lot in SV is a way to "cut off" the execution of a part of a tree. In my work I tend to redistribute the complexity of a tree in different node trees, since I can turn on or off those.

Will you consider such "on-off" feature for your new "Group" node concept?

Thanks

[Durman]

Will you consider such "on-off" feature for your new "Group" node concept?

Yes, I was thinking about that. But probably each node should have option to be freezed. I was writing about this here: #3058

[vicdoval]

Right now it can be done with Text Out + Text in Nodes, i guess is not super efficient but works

[rendetto]

Yes, I do use those two a lot, but here we are limited to transfer only simple data(numbers, strings...).
What will be ideal is to pass also whole objects like curves, surfaces, solids, etc... and WiFi looks a good candidate for this job at first glance

[DolphinDream]

Leaving the multi-tree update implementation complexities aside, I’d say a feature like this still has a place. I agree that hidden links within complex trees could be an issue (to debug and/or understand the complete picture), but IMO you should leave it up to the user to decide wether to rely or not on such a feature rather than imposing a certain method of managing trees. If a user finds it difficult to debug large trees that rely on this kind of WiFi links then maybe WiFi (across trees) capability is perhaps not a good solution for that user.

[vicdoval]

for the moment you can use:

the SNL script:

"""
in nodetree   s  d=''  n=2
in nodeName   s  d=''  n=2
in inputName  s  d=''  n=2
out data      s
"""
if nodetree and nodeName and inputName:
    data = bpy.data.node_groups[nodetree].nodes[nodeName].inputs[inputName].sv_get()

[Durman]

you should leave it up to the user to decide wether to rely or not on such a feature rather than imposing a certain method of managing trees.

Users are choosing which features to use and developers which to develop. If two trees are connected to each other why they should be separate tree then? For now we have known two disadvantages and it's not clear about advantages yet.

[rendetto]

Thank you @vicdoval! This SNL should go straight in to Templates.

@Durman I strongly agree that simpler solutions are by far the best ones. If a cross-tree WiFi node implementation complicates a lot the update system there is not much sense investing in it.

I personally separate node trees in order to reduce the node tree cluttering.
Also I use separate trees so I can turn off the calculations/update for those I don't need at some stages.
I also use the "display on-off" knob of those separate node trees, so I can reduce the cluttering in the viewport as well.

I find your "Group" node proposal very promising with its "in-out" and "on-off" functionalities while maintaining the update-ability. If it also contains a "display result" on-off knob I feel it will become an awesome addition to the workflow in SV.

@DolphinDream I also agree that user should choose the way to manage a workflow that suits best to his needs. There is no right or wrong if the thing works at the end, there are just bad and good practices I guess. The best thing with SV is the ability to seek for a solution through many ways.