Custom Warnings in Geometry Nodes [Proposal]

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.

image

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.

image

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.

15 Likes

This would allow the node group author to implement custom checks for invalid inputs.

My initial thoughts are:

  • What % of node authors would actually do this? Not imagine they might, but really do it. Perhaps the answer is “most node authors”. The answer might also might like… asking people if they would hand out flyers, if we print 1000 flyers. Everyone in the meeting says “Oh, sure!” - but , hardly anyone actually does it.

  • Will blender automatically translate the warning into another language?

  • Overall, I wonder if this is a solution in search of a widespread problem.

1 Like

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.

9 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.

1 Like

Something like Attach Exception node (with dynamically typed input and output) and string input with message (and boolean predicate…)/?