Many built-in nodes show warnings when there is a bad input value. For example, the Mesh Circle node warns when the passed in number of vertices is too low.
We want node groups to be able to create their own warnings. This document proposes a new Warning output node. If the Show input is true, the Message appears on the calling group node. This would allow the node group author to implement custom checks for invalid inputs.
While this node itself is fairly simple, the tricky part is to decide when its Show input should be evaluated. We don’t always want to evaluated it in all nested Warning nodes, because that would also cause evaluation of parts in the node tree that is currently unused.
For example, in this case the Generate Mesh node would always be evaluated for both seeds regardless of the Switch.
This document proposes that the Warning node is only evaluated if any group output is actually required. This loosely matches the behavior of built-in nodes as well. This would solve the issue shown above, because in one of the groups the geometry output is not required.
Future Improvements
The described behavior can still result in more evaluation than desired though. Therefor, it may become necessary to use a more fine-grained heuristic in the future. For example, the warning node might only be evaluated if one group output of a subset of all group outputs is used. The mapping from warning node to the set of group outputs could be manual or somewhat automatic based on what group inputs they depend on.
Warnings might require different severity levels (info/warning/error) but we need some good definitions for when to use what first.
By default, warnings propagate all the way up to the modifier, but it might be useful to be able to quiet warnings on a per node or group node basis to avoid spamming the caller with potentially useless warning messages.
19 Likes
Just like that currently did for names of sockets in node editor.
1 Like
Personally, I’d love to have this. Currently, node groups are essentially black boxes, and if there’s a problem you have to figure out what’s going wrong yourself.
It also brings node groups closer to being first class citizens in node trees. Currently, there are quite a few options that are available for nodes, but not for groups (warnings, enums, ramps etc.). As Blender moves further with transitioning more parts to use assets, I think it’s important that those assets have all the same functionality as the built-in systems.
Having the ability to tell people what they’re doing wrong is very powerful. Maybe not everyone will use the warnings, but using that as an argument for not adding them at all seems silly.
11 Likes
This functionality should definitely exist in some way, there’s no way around it since we want node groups to be able to act like builtin nodes.
I’m not sure this will be fine-grained enough though. For example, if some group inputs are only used depending on the value of other group inputs, the group shouldn’t give warnings for them.
I had always imagined warning nodes being “attached” to other nodes, so they would only evaluated when the other node evaluated. Ideally this would come with some different UI in the node editor, to make that attachment obvious.
2 Likes
Something like Attach Exception node (with dynamically typed input and output) and string input with message (and boolean predicate…)/?
I’ve implemented an initial working version for this proposal: #125544 - Geometry Nodes: support custom warnings in node groups - blender - Blender Projects.
For example, if some group inputs are only used depending on the value of other group inputs, the group shouldn’t give warnings for them.
These inputs could just be used to control the Show input too. I think the more tricky thing is to make it dependent on whether group inputs or outputs are used and not so much what value they have.
There is still value in this more fine grained control, but I feel like for the majority of node groups, this simpler design fulfills all requirements already. The main question for me is whether there is a good upgrade path to when we need to support more fine grained control or whether that can be implemented in a way that still keeps the proposed simple version working the same way.
Currently, I think that’s possible, but I need to think a bit more about it.
I had always imagined warning nodes being “attached” to other nodes, so they would only evaluated when the other node evaluated. Ideally this would come with some different UI in the node editor, to make that attachment obvious.
Not sure if it makes sense to attach it to specific nodes. It can work, but it can also work to attach it to nodes, sockets, links or group inputs/outputs. All of these cases provide very similar functionality.
I could imagine giving the Warning node a boolean output that just forwards the Show input. This can be “mixed” into other values (e.g. with a Switch node) to make sure that the Warning node is evaluated if that other value is used. If this extra output is not linked, the node could fall back to always evaluate if the node group is evaluated.
4 Likes
