-
Notifications
You must be signed in to change notification settings - Fork 25
Function Graphs
Function graphs have gone through quite a few changes.
In the latest revision, function graph nodes now have execute pins. As well as being able to create custom functions that can be called in any other function graph.
The execute pins tell the function graph in what order the nodes should be executed. This not only helps build the shader more efficiently, but also allows for more complex features such as for loops and calls to other custom functions. Execute pins are the red pin on every node.
The following nodes do not require execute pins:
- Get Variable
- Constants
Every other node requires an execute pin in order to establish flow. The numbers you see next to the execute pin graph line is the order it will execute in. You can have multiple connections going from the out pin, but you can only have one connection going to the in execute pin. The out execute pin is always on the right side of the node and the in execute pin is on the left side of the node.
Function graphs can indeed run without an execute node in them. But, it causes up to 2x initial load performance loss. By using an execute node, you bypass the 2x initial load performance loss.
Why is it that way? By default without an execute node, the graph runs backwards from the specified output node to find the beginning of the graph. Next it goes through the graph forwards to properly order the nodes for executing. Adding an execute node at the beginning avoids having to run backwards through the nodes, and thus only ever has to run through the nodes forward to build the execute order.
Afterwards, in both cases, it caches the execute order, so any future runs of the specified function graph does not have to rebuild its execute order. The cache is rebuilt when a function graph node is changed connection wise, a new output node is specified, or a node is added or removed.