Node groups

[ly29]

A node group can be seen as code block. It is very beta right now but works.

Plans: recursion, iteration, do while.

For recursion the key issue is to change update system to use switch node as a if statement for flow control.

Iteration and do while is pretty straightforward to do inside of the current system.

Other issues to resolve:

• I/O of node groups inside a layout
• Letting live in the same layout where they are used
• Editing socket types
• Recursive node groups

[ly29]

Also a big question is what nodes can be inside of a node group in a safe way.

[Kosvor]

Socket which gives the index of the current iteration of the loop could be used in conjunction with 'list item' node to obtain a new item of the list for each iteration

[zeffii]

Yes an index socket! makes sense.

@ly29 is this part of the 0.5 push?

[ly29]

No, I would like it to be but lets do it a bit afterwards...
Many big improvements already in 0.5. Basically documentation and some bug hunting left.

[zeffii]

cool, that's the response I hoped for

[ly29]

I really want to finish the 0.5 push very soon.
Then:
Clean up nodes
Fix sockets
Object nodes
Text nodes
Groups

And then:
0.6...

[ly29]

Socket editing, move up, down, remove, rename and change type.

[zeffii]

Looks cool! i'm getting flashes of a Symbolic approach, no code in the nodes but one massive symbolic evaluation step for entire tree or subtrees.

[ly29]

For recursion to work switch node has to be lazily evaluated.

This requires some fundamental changes to the order that nodes a processed.

Consider switch like a if statement.

First process the things needed for state, then evaluate the nodes going into the True or False input. Today everything is evaluated but switch only decides which data to pass on.
Now flow switch is promoted to a flow control node but it requires some rethinking about how things should work.

[ly29]

In update system there are nice methods for working with parts of node trees. But somewhat badly names, make update list from nodes would perhaps be a better name of this node.

make_tree_from_nodes(node_list, ng, down=True)

Where node_list is list of node names for the node tree ng. down is set to true if want down stream nodes

from sverchok.core.update_system import make_tree_from_nodes
true_nodes = [s.links[0].from_node.name for s in switch_node.inputs[1:switch_node.switch_count+1] if s.is_linked]
if_true_update_list = make_tree_from_nodes(dep_nodes ,ng, False)

The main is that I am bit uncertain where to put machinery for this in clean way.

Inside of the node feels a bit dirty but putting inside the update system feels a bit strange also.

[zeffii]

I'm not up-to-speed with node_groups, having never used them in Sverchok. But my opinion about the naming of that function "make_tree_from_nodes" is that perhaps it should be get_disjoint_graphs_from_nodetree, and maybe have it in sverchok.core.dependency_graph. Separating the routine of making the graph from the routine that traverses it

[ly29]

What the extremely badly name make_tree_from_nodes actually does it that it creates an sorted list for nodes that either are the nodes that are downstream of upstream from the the nodes passed as a list.

From the red node, blue is up, green is down.

What it does is that takes a node to eval to or to eval from and builds a sorted node order from the node graph as flat list. It is primarily used for changed called by updateNode

The function that actually builds the sorted list is called make_update_list and is quite ugly. It should/could be called topological sort.

[ly29]

The badly named make_tree_from_nodes creates a (sub)set of the whole graph, either down or up from the passed nodes. It returns a topologically sorted list whichs gives a safe order of evaluation.
Every sverchok node tree is translated into a simple list of function calls.

n1.process()
n2.process()
n3.process()
n4.process()

Where each node knows the name of its inputs and the topological sorting ensures safe evaluation order.
Node groups work right now by doing something like this.

n1.process()
n2.process() # group, the process is called from inside of the group node
     g1.process()
     g2.process()
n3.process()
n4.process() # another group call, same nodes are called again
     g1.process()
     g2.process()
n5.process()

What I want to do know is change this around and introduce if statements with the switch node.

n1.process()
if state
   n2.process()
else:
  n3.process()
n4.process()

With introduction of iteration for flow control and groups inside of groups we then have a Turing complete language (I think).

[ly29]

Regardless is probably a good idea to split the file up into two parts.

[ly29]

Even further the make_update_list doesn't even require connect DACs, it can deal with complete layout and eval order might jump back and forth between separate graphs.

Of course for error handling etc it makes sense separate nodes in separate node graphs.

[nortikin]

now is clear. Naming - secondary. primarly you explained everything

[portnov]

Is it possible to reuse groups in one setup? For example, if I create a group which duplicates input mesh N times, and then I want to apply this group twice, for two different inputs...

[ly29]

Yes.

This part needs to be redone however partly, which is why it is in beta.

[snovvfall]

Is it a good idea to use a separate layout as a group and put there some sort of Wifi nodes for input and output for another layouts?

So it will be like:

1. user makes some nodes
2. adds "Wifi in" which leads to another layout
3. in that layout "Wifi out" connects to some other nodes
4. "Wifi in" as an output pushes data back to first layout
5. "Wifi out" receives data and sends it to other nodes the user nees
6. ...
7. profit

So it all comes to making Wifi node that can transfer data between layouts. Or is it even harder to code and make it work than the thing you already did? I use groups a lot ever since you implemented them, would be glad if they improve.

[ly29]

It is a very good idea in general. My thinking about sverchok has become clearear lately, since I developed groups I have reached an deeper understanding of how I think it should work.

[pierdr]

Hi, I think it's not so straight forward to understand how to manage group inputs.
Any suggestions?

[nortikin]

@pierdr just create group connected with outer nodes allready. It is beta version, and works as it works. sorry

[pierdr]

@nortikin Thanks! It works. Sverchok is super! Keep going!

[nortikin]

follow vk.com group of #sverchok there is more stuff.

[Durman]

Group node has problem with import/export.

1. Before import 2. After import 3. After rename

[nortikin]

i see it became bigger ))
#1485
here was discussed and
#1251
and
#1230

[ly29]

I thought I had solved that. Make new issue and tag me.