Geometry Nodes Evaluator 3.0 #98492

New Issue

Jacques Lucke · 2022-05-30T12:24:01+02:00

Jacques Lucke commented

2022-05-30 12:24:01 +02:00

The geometry nodes evaluation system is responsible for parsing and executing the user generated node tree efficiently.

Some History

The first evaluator was very simple. It parsed and executed the node tree recursively, executing every node at most once. It was single threaded, didn't support any conditional execution and the node tree complexity was bounded by stack size.

The second evaluator (introduced in May 2021) offered many more features already. Most importantly it introduced support for multi-threading, lazyness and it was non-recursive.

Now, we start to reach the limits of the existing evaluator, which should be overcome by the next evolution of the evaluator.

Goals

Keep the good parts of the existing evaluator: multi-threading, lazyness and non-recursiveness for node chains.
Make evaluator independent from the modifier, so that it can be used in different contexts.
- The existing evaluator can essentially only be used by a modifier for the root geometry node tree.
- To support "sub-contexts" in geometry nodes (e.g. loops or simulations) it has to be possible to evaluate a node tree that's not a root node tree in a modifier.
Make the evaluator independent from geometry nodes.
- This is similar to the previous goal, but a bit stronger.
- A node in the evaluator shouldn't always have to correspond to a node in a geometry nodes tree.
  - This allows us to insert additional nodes dynamically, or to combine multiple geometry nodes into one.
- Makes it easier to test isolated parts of the evaluator without .blend files.
Don't require inlining of all node groups.
- The current evaluator essentially inlines all node groups into a single graph before evaluation.
- That has a fairly high constant overhead when only few of the nodes are used.
  - This becomes more common with high level node groups, where large parts of a group are disabled with a switch node.
- Instead, we want that a node group can also be executed like any other node.
- A node group should be able to use the evaluator internally.
Support preprocessing node groups:
- This is related to the previous goal.
- When node groups don't have to be inlined (they still can be), preprocessing can happen on the node group level.
- For example, a node group only consisting of a couple of math nodes, could be combined into a single multi-function, which avoids executing these nodes all the time.
Support lazyness across evaluator boundaries.
- The current evaluator supports lazyness within a (flattened) node tree, but all inputs to the evaluator have to be computed eagerly and all outputs are computed all the time.
- Instead we want that the evaluator can lazily request inputs as they become required. Furthermore, the user of the evaluator should also be able to request the outputs lazily.
- This is to keep lazyness working correctly even when node groups are not all inlined, because then multiple node groups can lazily request data from each other.

The geometry nodes evaluation system is responsible for parsing and executing the user generated node tree efficiently. ## Some History The first evaluator was very simple. It parsed and executed the node tree recursively, executing every node at most once. It was single threaded, didn't support any conditional execution and the node tree complexity was bounded by stack size. The second evaluator (introduced in [May 2021](https://developer.blender.org/rBb084b57fbf6d2b6c2a1adb2192f5d82581cede5c)) offered many more features already. Most importantly it introduced support for multi-threading, lazyness and it was non-recursive. Now, we start to reach the limits of the existing evaluator, which should be overcome by the next evolution of the evaluator. ## Goals * Keep the good parts of the existing evaluator: multi-threading, lazyness and non-recursiveness for node chains. * Make evaluator independent from the modifier, so that it can be used in different contexts. * The existing evaluator can essentially only be used by a modifier for the root geometry node tree. * To support "sub-contexts" in geometry nodes (e.g. loops or simulations) it has to be possible to evaluate a node tree that's not a root node tree in a modifier. * Make the evaluator independent from geometry nodes. * This is similar to the previous goal, but a bit stronger. * A node in the evaluator shouldn't always have to correspond to a node in a geometry nodes tree. * This allows us to insert additional nodes dynamically, or to combine multiple geometry nodes into one. * Makes it easier to test isolated parts of the evaluator without .blend files. * Don't require inlining of all node groups. * The current evaluator essentially inlines all node groups into a single graph before evaluation. * That has a fairly high constant overhead when only few of the nodes are used. * This becomes more common with high level node groups, where large parts of a group are disabled with a switch node. * Instead, we want that a node group can also be executed like any other node. * A node group should be able to use the evaluator internally. * Support preprocessing node groups: * This is related to the previous goal. * When node groups don't have to be inlined (they still can be), preprocessing can happen on the node group level. * For example, a node group only consisting of a couple of math nodes, could be combined into a single multi-function, which avoids executing these nodes all the time. * Support lazyness across evaluator boundaries. * The current evaluator supports lazyness within a (flattened) node tree, but all inputs to the evaluator have to be computed eagerly and all outputs are computed all the time. * Instead we want that the evaluator can lazily request inputs as they become required. Furthermore, the user of the evaluator should also be able to request the outputs lazily. * This is to keep lazyness working correctly even when node groups are not all inlined, because then multiple node groups can lazily request data from each other.

Jacques Lucke commented

2022-05-30 12:24:01 +02:00

Added subscriber: @JacquesLucke