This is used as base class for the compute contexts for group and evaluate
closure nodes. Furthermore, in the future this can be used for the compute
context that is passed into field evaluation.
Pull Request: https://projects.blender.org/blender/blender/pulls/139377
Previously, the modifier name was used to identify it in a compute context or
viewer path. Using `ModifierData.persistent_uid` (which was only introduced
later) has two main benefits: * It is stable even when the modifier name
changes. * It's cheaper and easier to work with since it's just an integer
instead of a string.
Note: Pinned viewer nodes will need to be re-pinned after the change.
Pull Request: https://projects.blender.org/blender/blender/pulls/138864
This adds support for having viewer nodes in closures. The code attempt to
detect where the closure is evaluated and shows the data from there.
If the closure is evaluated in multiple Evaluate Closure nodes, currently it
just picks the first one it finds. Support for more user control in this case
may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or
foreach zone, it will automatically use the inspection index of that zone to
determine what evaluation to look at specifically.
Overall, not too much had to change conceptually to support viewers in closures.
Just some code like converting between viewer paths and compute contexts had to
be generalized a little bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/137625
While `ComputeContextBuilder` worked well for building simple linear compute
contexts, it was fairly limiting for all the slightly more complex cases where
an entire tree of compute contexts is built. Using `ComputeContextCache` that is
easier to do more explicitly. There were only very few cases where using
`ComputeContextBuilder` would have still helped a bit, but it's not really worth
keeping that abstraction around just for those few cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/137370
For various purposes we traverse the computation done by a node tree (e.g. for
gizmos and socket usage infeferencing). For that we generally have to keep track
of the compute context we're in at any given time. During the traversal, it's
common to enter and exist the same compute contexts multiple times. Currently,
we'd always build a new compute context when that happens. That happens even
though the old one is generally still around, because other data may reference
it. This patch implements a `ComputeContextHash` type that avoids rebuilding the
same compute contexts over and over again.
I'm considering to also replace the usage of `ComputeContextBuilder` with this
cache somehow, but will see how that works out.
The reason I'm working on this now is that I have to traverse the node tree a
bit again to find where closures might be evaluated. I wanted to be able to
cache the compute contexts for a while already.
Pull Request: https://projects.blender.org/blender/blender/pulls/137360
