Script Modifier - Maybe not an anti-pattern now - here's why
I'm re-proposing something someone proposed a while back that was at the time considered an anti-pattern. With geometry nodes, I don't think this is any longer true. If you want to automate a full pipeline that involves both geonodes and scripting, then you need some way of getting it merged into the process, either as a Script modifier that you add to the stack, or a script node that you put in the geonodes graph. "Pipeline" might be added to the Categories for this site.
1 Comment
I would also love to see a "scripting" node, where I can either execute a small amount of python code, or a specific python function.
Aside from pipelining, I have a different use-case. My main modeling workflow is in geo-nodes, so that I can make fine adjustments to my models once I have my lighting subject and camera setup.
When doing so I often need to compose many math functions to calculate proportions, or appropriate placement. This makes my node trees balloon to the point of needing 5 or 10 math nodes to accomplish something I usually only need one line of python to accomplish. An example is the 5 nodes needed to calculate the length of a hypotenuse using Pythagoreans theorem. This kind of calculation isn't super complex, but is an example of the exponential node-tree growth, as there are only 3 mathematical operations happening.
My current work-around has been to save these "math-function" node groups as assets. However this method makes debugging or refactoring a node tree a headache, as I may encounter a problem caused by an incorrect noodle hookup in a math node that is buried 4 or 5 node groups deep. And it might be an edge-case where fixing the one bug breaks something else.
A scripting node would drastically reduce bugs, because the math behind a "math-function" node would be immediately visible at the top level of the node group, rather than deeply abstracted away.
An alternate implementation of this concept can also simply adding "custom function" as another math-node option. The "math node" implementation would allow an arbitrary number inputs and outputs. However, the inputs and outputs must be of the type factor. The node has a text box, and accepts standard python math notation. However, the only way for a variable to be accessible is if it has an input. I think that the "Node" tab in the N menu might be the most efficient way to actually interact with this kind of node.