Author Topic: SBSGraph.connectNodes ignores leftNodeOutput/rightNodeInput values  (Read 5213 times)

I'm running into an issue while creating complex materials.

I have a node which can output diffuse or basecolor based on a switch. (not relevant to the issue)

If I make an explicity connection from an output to an input, it ignores the values and connects to the first acceptable match on the left node.

If I run the code below, it will connect the 'diffuse' output on the source_node, to the 'input' on the target_node.
Code: [Select]

This is the output order on the source_node:

Now if I reverse the order so that basecolor is first, it connects properly:

The temporary fix is to retain proper order via Designer, but it's extremely unreliable when managing a complex library of materials or generating them via pysbs.

This has become a huge problem for us, so any suggestions or confirmation would be appreciated.


This should work.
Make sure aLeftNodeOutput is exactly the identfier string of the node (not the label).
If it still doesn't work, please send a sample we can debug

Hey David,

Thanks for your response, it reminded me of how I was making that connection differently elsewhere.

The connection logic I was using does the following:
- Get usage of src_output and tgt_input
  - If src_output.mUsage[0] == tgt_input.mUsage[0]:
    - Make connection.

What I failed to do in this particular instance, which I was doing with other successful connections is the following:
- Get usage of src_output and tgt_input
  - If src_output.mUsage[0] == tgt_input.mUsage[0]:
    - get_ids = src_output.mIdentifier, tgt_output.mIdentifier
    - Make connection.

Stupid oversight on my part from a lack of sleep.

Although, is there a reason why the default behavior is to connect to the first compatible input, even when 'aLeftNodeOutput' provides an invalid value (regardless of whether its valid)?

I understand the need for it when 'aLeftNodeOutput=None' attempts a default connection; however, it seems counter intuitive to use the same behavior for an invalid value, rather than raise an exception when an incorrect user defined output/input value (identifier) is provided.

Thanks for your help.
Last Edit: June 10, 2019, 05:30:41 pm


It's a good point. I would agree it's a bug that an invalid input name is considered the first compatible input