The goal of this thread is to find the right way to handle dynamic socket visibility. This document presents a few different options.
We already have a few built-in nodes, that change the visible inputs depending on some setting. For example, the Curve Line node changes some sockets depending on whether it is in Points or Direction mode.
We want to generalize this a bit more such that:
- The visibility of some sockets can depend on the value in other input sockets. Currently, we only allow the visibility to depend on node properties that are not sockets. Those will eventually become sockets. If e.g. a boolean input is linked and it controls which of two other sockets is visible, both of those will be visible, because the boolean input is in an undetermined state.
- At a minimum boolean and menu sockets can affect visibility of other sockets. Maybe it could also be useful to dynamically show sockets when a data block input is non-empty.
- Group nodes should also have the ability to show and hide sockets dynamically.
Keep in mind that socket visibility should be known statically. So hiding and showing sockets dynamically should always work even if the node tree is not actually evaluated by a modifier or operator.
Option 1: Automatic Inferencing
The idea here is that we could look at the node tree and automatically determine which inputs affect which other inputs are used. For example, in the node tree below we can statically determine that the Length input is only used when the Direction boolean input is true.
The main benefit here is that no extra user input is required and things generally just work. Also it guarantees that hidden inputs definitely don’t affect the result.
Furthermore, it could just keep working when grouping all nodes in a new nested node group without extra work.
A potential problem occurs when the automatic inference is not smart enough to realize that some input does not affect the result. In this case, the user would have to add a “dummy” Switch just to please the inferencing algorithm. I’m not sure how often that issue would come up in practice. Generally, we can also always try to make the inferencing smarter if that problem comes up.
Another potential problem is that this approach can only determine the visibility of input sockets, but not for output sockets if that is necessary.
Option 2: Explicit Control in Node Group Interface
The idea here is that the user can explicitly specify which sockets affect the visibility of other sockets in the node group interface panel. For example, an interface socket could store some setting like “hide if …” where the user can choose from a dropdown.
The nice thing with this approach is that it is very explicit and easy to understand for simple cases.
For more complex cases where the visibility depends on multiple inputs it’s more difficult though, because suddenly logic operators like and, or and not are necessary as well as more complex comparisons.
Generally, this has to be set-up manually, but this may be okay when authoring node group assets.
Changing the visibility of input and output sockets works in the same way with this option.
A problem might occur when the socket visibility is configured in a way so that sockets that can still affect the output are hidden.
Option 3: Explicit Control in the Node Group
We could also add a new Socket Visibility output node that has a boolean input for all interface sockets. The node group can then manually compute the visibility of each input and output.
Note, the set of nodes that are allowed to be used to compute the visibility may be limited, such that the analysis can be done statically and does not require a full node tree evaluation.
The benefit here is that it is somewhat straight forward to understand, but also requires extra work. Instead of having a “logic editor” in the node tree interface panel, one can use more familiar switch and boolean math nodes though.
Since this node also depends on the current node tree interface, it can’t be moved to a sub-group.
This approach also has the problem that sockets that still affect the output may be hidden.
Overall, it’s not obvious to me yet which approach is best. Maybe a combination is necessary as well. For example, explicit control (option 2 or 3) can be used for output socket visibility while automatic inferencing is used for input socket visibility.
