Feedback on breaking Python API changes for shader nodes

Feature & Design Feedback
2

tl;dr: I consumed the API, i’m really bitter about the experience, any change is an improvement, just go for it, the sooner the better.

For a personal project I’ve recently spend a healthy amount of time with our python node api, and honestly, don’t worry about breaking it, the whole thing is in such a state of disarray breaking it further isn’t going to surprise anyone working with it already, they know/expect it is going to break at one point.

Some random issues I ran into:

  1. You cannot tell from a nodes type X (nor any of its base types) if it could go in node graph of type Y, nor is this available in the python documentation , example : ShaderNodeMath can go in both shader and geometry nodegraphs , how can you know? only by trying to insert it and see if it errors out.

  2. the py docs on some nodes are abysmal, example GeometryNodeSwitch has 26 input sockets, none of them are in our docs, this is not limited to geometry node, ShaderNodeMath isn’t any better.

  3. Given you’ll have to know the socket names to program against them (unless you just want to use indexes, which i’ll be honest, doesn’t seem like worse solution at this time), the only way to get them is to insert a node into a graph and query its inputs. Which isn’t great, but once you do, at least the socket names you have to program against make sense right? Nope wrong again! GeometryNodeSwitch’s inputs: Switch, Switch_001, False, True, False_001, True_001, False_002, True_002, False_003, True_003, False_004, True_004, False_005, True_005, False_006, True_006, False_007, True_007, False_008, True_008, False_009, True_009 , it’s outputs: , Output, Output_001, Output_002, Output_003, Output_004, Output_005, Output_006, Output_007, Output_008, Output_009, Output_010, Output_011 very helpful guys! really helps writing nice clean code. (again picking on GeometryNodeSwitch here, since it’s just shooting fish in a barrel there but similar offenders are ShaderNodeMath,FunctionNodeRandomValue, GeometryNodeAttributeTransfer, GeometryNodeCaptureAttribute, GeometryNodeRaycast, etc etc etc)

  4. All the problems from 3 are hidden from the user with some clever UI tricks, GeometryNodeSwitch hides most of it’s inputs based on the input_type field, well that’s at least something… you can set the field and check if a field is visible or not, and generate your own documentation… ha! Nope! the hide field, returns false for all sockets. Not very helpful. you can get through this data by writing a helper function and query the SOCK_UNAVAIL bit in flags but lets be honest… you can’t expect this from people consuming the python API

def is_really_hidden(socket):
    return (ctypes.c_short).from_address(socket.as_pointer()+162).value & (1<<3) != 0

Overall I found working with the node api rather unpleasant, i feel like (some of) the nodes have fundamental design issues that are being hidden in the UI layer, I’d like to say the BPY nodes api feels like a mere afterthought, but even that seems a little bit of a stretch, no thought appears to be given at all

so if you want to break a few more nodes by giving things more sensible names, go for it, break things, the only way is up from where we are, you literally can’t make the experience of working with nodes from python any worse (then again, please don’t take this statement as a challenge)

10 Likes