Is this undocumented? Node Socket-types in the Group Interface Panel

Hello Blender friends. I’ve been working on a node-based addon for Blender, and I have implemented groups (that was a LOT of work). However, there is a fatal bug in Blender that occurs when some data is requested, but it is not defined anywhere- that data is the node-socket types that are apropos to the current Node Tree type. The problem is, I can’t find any documentation about how to define this data, nor about where the data is being requested from. I even tried to modify the UI code that calls the function, but all I have been able to discover is that it calls a built-in operator that I think is defined in C.

Here’s a video of the data it can’t find and the crash occuring.

I have seen one addon that does define it- Sverchok, but I can’t figure out how they did it. Any ideas?

OOPS. My mouse cursor doesn’t show up. Well, the second I click on the drop-down, Blender freezes and crashes to desktop after a few seconds. Here’s a pic of the dropdown:
And the same goes for the output section, the dropdown is busted bc there is no data to fill the list.

Creating documentation about node groups is in Blender developers’ long list of todo. For now these lines can help.

1 Like

Thank you, @Random. I spent about four hours searching and got nowhere on my own :smiley:
I’ve learned a lot about nodes while making this addon. I definitely plan on making a blog post or guide once I feel like I’m “finished” enough to do so. But I still have so much more to learn!
It’s no surprise to see a code example from Sverchok. I take it you’re a Sverchok developer? You guys are probably the only ones who made group nodes work in a complex addon. Hats-off to you.

Thanks. Yes I’m one of the Sverchok developers.) Sverchok is not only one or at least not first. I as far as I know Sorcar was the first but probably there was others less popular (paid) add-ons. It took for a while to reveal all node group secretes - Node groups instead of monads · Issue #3319 · nortikin/sverchok · GitHub

Also there are problems in node groups API. Recently (about 3.0) the path disappeared in custom node groups (probably it’s worth to create a bug report) so now it’s not clear whether you are editing a group or a base tree. Also the path keeps information only about previous trees but not about nodes via which sub trees were entered. It makes execution of groups twisted and limited.

1 Like

Oh, I have seen Sorcar, too. I think I snatched their code for my Make Node Group operator, since it is GPL and it works. I have learned a lot from both Sorcar and Sverchok.

I ran into a similar issue when parsing node groups- I had a situation where I didn’t know which instance of a node tree I was in, since the nodes inside the groups are shared. I realized the way to know which one was which: to keep track of the unique path from the ENTRY of the tree until the specific node. So, I wrote a function to traverse IN to group nodes and back OUT, and I developed a system to keep track of the ins and outs. It kept track of every node and socket with a “signature”, which looked like ((tree path), (node name), (socket name)). The tree path is the names of currently edited tree, and the group nodes the node is in (in order, as they may be nested). That way, every instance of every node is uniquely identified. Because it used the names, it was also hashable, so I could add it to a Python set, which was useful on many occasions.
It may seem odd to do things this way, but there are two facts you should know! 1) I am not nearly as clever as the fellas who do dynamic programming or use OOP design patterns, and 2) my addon is more than anything about sorting the hierarchy. I’m making a “Rigging Nodes” addon and so it matters very much which order the nodes are executed in. It will also be useful to be able to edit the data after it is taken from the tree. Finally, I wish to separate execution from representation, so that in the future I can use the same execution system with e.g. a text-based markup language instead of a node tree.
Anyhow, after I read the tree from Blender, I use the data in the node tree to create my own set of “node container” classes for execution. The N.C.'s hold all the data from the nodes, including the “signature” and their connections. Each one is a unique instance, not a linked copy like the nodes inside of group nodes. So, I can give each one its own execution data and keep track of which have been executed, and I can keep a link to the Object or Bone the node created. At this point I can also add new N.C.'s to the tree if needed, for example, to represent data inferred from the context ( e.g. data conversion between different socket types that are incorrectly connected), or to expand nodes that may represent multiple objects (eventually I want to make “chain” nodes that represent a number of bones), etc… In the future I can probably use this “expansion” idea to deal with node groups more efficiently.
One of the nicest things about this system is that it helps me to locate and deal with cycles in the graph, by marking certain kinds of connections as “hierarchy connections”, rather than mere data connections. The data connections are ignored when sorting the graph, so later nodes can affect earlier nodes. I needed to do this because Blender actually allows this in its depagraph. A bone can have a driver than affects its own parent bone! This was a really vexing problem before I figured this out.

It isn’t quite the same as the problem you described, but I think it may be a solution, since it sidesteps the question of “which tree am I editing?”. Well, you need to know the base tree, in order to trace the lines all the way through the tree from the beginning to the end. But once you have a reference to the root nodes in the base tree, you can find every node in the tree including all of the groups, in order, and with a uniquely identifiable “signature”. Then you don’t need to know where you are at all, since you know where you’ve been!

I don’t know if that is helpful, but I wrote it in the hopes that it is interesting, since I think I solved the problem in a very different way. I have a feeling Sverchok does group nodes more efficiently, but probably doesn’t place as much emphasis on hierarchy and execution order. Thanks again for the reply and for the help.