I just developed my first custom node (nothing special just to help reduce graph clutter and duplication). Everything was working when I had the nodes on the main graph. I then selected everything and right-clicked > create custom node.
I have implemented some watch nodes inside the custom node so I can see the data coming out.
In this image, you can see my node has 276 items in its list. However when you plug in watch nodes into each export slot that number goes over a hundred thousand.
DYN and package with custom node are in the link below.
Let me know if you need more information. I think I provided everything that is needed but you never know. Thank you for any and all help you are able to provide.
After stepping away for the night I have figured out that it has to do with the lacing and levels. I have not solved the proper lacing/levels but I am continuing to work on it. I will keep posing back here.
I am still not sure why a cross product is being produced at some point but I did find a solution. Rather than a single node, I broke it up into multiple nodes. Each individual node is working as expected.
I think it’s actually because the custom node returns everything as a dictionary, while the individual outputs return the actual list. Each dictionary is counted as a single object rather than a list of objects.
Thank @Nick_Boyts,
I was wondering that too. What you said does make sense but it does not account for the extra elements. If you look at the structure and amount of elements in the last Data watch nodes they do not match.
This one is from the nodes being executed directly in the graph and is the expected output.
This one is the output from the custom node. My guess is that at some point something is operating in a cross-product manner but I cannot figure out where.
Splitting it up into two nodes did the trick. It may have just been too much for one node.
Your lacing is set to Auto so you might try setting it to Shortest. Also keep in mind that inherent/defined lacing on your nodes will work differently once it’s all wrapped inside a custom node. Sometimes that does mean modifying your graph.
I did try shortest but it did not solve it. I was wondering if some of the internal nodes inherited the lacing. Some of the internal ones are set to longest. I think this may be where some of the problems came from. I left those nodes out of the two smaller custom nodes.
When you originally developed this section in the main graph, were you running it on one set of inputs or multiple? Always develop your custom node for a single set of inputs and then use list levels and lacing on the node to handle additional input levels.
What do you mean by one set of inputs? One list structure?
Here is the structure of the inputs. As you can see there is quite the variety of list structures. My thought was that the dataIN port is what’s causing the main problem because it has nested lists.
You may have already gotten this far but I’ll lay it all out for clarity’s sake.
Let’s say you have a partial graph with two inputs, input1 and input2. Input1 takes a single item and input2 takes a list. Your first step would be to get this part of your graph to work with a singular set of inputs - a single item for input1 and a single list for input2. If you plan on leaving this section of logic as a partial graph (not a custom node) then at this point you would begin modifying list levels and lacing to allow your graph to work with multiple inputs (multiple items for input1 and multiple lists for input2). If you’re creating a custom node you’re done. You would wrap everything in a new custom node as-is and then use list levels and lacing on the custom node to handle multiple inputs.
Nodes resolve themselves based on their expected inputs. If a node expects a singular input and you provide a list it will resolve each item in that list as a separate input. If you draw up your logic to work on multiple inputs and then wrap that in a custom node, the node is now expecting multiple inputs for each iteration/resolution. This will almost certainly cause problems with the outputs if that is not the intended structure.
to expand on this - carefully look at the type hints for each of your custom node inputs - the node will replicate depending on which inputs expect lists or single values or - var[]..[] (arbitrary rank) - that won’t replicate at all - for that input, you have so many inputs that it’s probably pretty difficult to reason about replication.
I would probably make them all mycoolinput : var[]..[] and do the replication inside the custom node.
