Mistake in fe52284be9.
The attribute filter created by the geoemtry nodes evaluation system
doesn't work in this case because the the conversion from curves to
points is internal to the node, just an implementation detail.
Pull Request: https://projects.blender.org/blender/blender/pulls/137614
This adds a new Instance Bounds nodes which provides an easy and
efficient way to get the bounding box of each instance.
Nested instances or not taken into account to compute the bounding
box. That would result in a major performance degredation because
one would have to basically realize all instances to do that.
Also see #135933 for some examples.
Pull Request: https://projects.blender.org/blender/blender/pulls/135933
The Cryptomatte node only works with the first view layer in a setup
where a view later is called ViewLayer and another called ViewLayer.001.
This is because the code used a prefix check to match the view layer to
the Cryptomatte type name, and since ViewLayer is a prefix of the other
ViewLayer.001, the check always matches the first ViewLayer.
To fix this, we just remove that guard condition and rely on later
checks.
Pull Request: https://projects.blender.org/blender/blender/pulls/137659
The goal here is to avoid having to cast to and from `ID` when getting the
evaluated or original ID using the depsgraph API, which is often verbose and not
type safe. To solve this, there are now `DEG_get_original` and
`DEG_get_evaluated` methods which are templated on the type and use a new
`is_ID_v` static type check to make sure it's only used with valid types.
This allows removing quite some verbosity on all the call sites. I also removed
`DEG_get_original_object`, because that does not have to be a special case
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/137629
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
This patch turns the options of the Tone Map node into inputs.
In the process, a few changes were made. Input ranges were adjusted to
remove artificial limits. The papers indeed mention those limits, but
they were only mentioned as typical values, not valid ranges.
- The Key option is no longer limited to 1.
- Gamma is no longer limited to a value of 3.
- Intensity is no longer limited to [-8, 8].
- Contrast is no longer limited to [0, 1].
A few renames were done to clarify options and match the reference
papers.
- Offset was renamed to Balance, since it is not really an offset, but
balances between shadows and highlights. This can be looked up in the
paper.
- Correction was renamed to Chromatic Adaptation, since it doesn't
really correct anything.
- Adaptation was renamed to Light Adaptation to distinguish from
Chromatic Adaptation and now default to global tone mapping, since
this is more useful by default.
Reference #137223.
Pull Request: https://projects.blender.org/blender/blender/pulls/137589
This adds a simple `compute_context_for_edittree` function that returns the
"active" compute context for the given node editor. This is used in various
places, but previously one had to construct the compute context in multiple
steps (first find the root context (modifier/operator), then handle the tree
path). Since the edittree already has a specific active context, there should be
an easy way to retrieve that.
This also adds a few extra check that avoid redundant work that was done before.
Pull Request: https://projects.blender.org/blender/blender/pulls/137525
This makes accessing these properties more convenient. Since we only ever have
const references to `CPPType`, there isn't really a benefit to using methods to
avoid mutation.
Pull Request: https://projects.blender.org/blender/blender/pulls/137482
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
Now, if no closure is connected to the Evaluate Closure node, it behaves like if
it is muted. Previously, all outputs were just defaulted and the inputs ignored,
but that's less useful.
Pull Request: https://projects.blender.org/blender/blender/pulls/137418
Previously, internal links used the same heuristics as most other nodes. However,
this is more problematic here, because I intend to use the same internal links
for the case when no closure is connected. The behavior in this case should not
change in the future if we decide to change the heuristic for internal links for
muted nodes.
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
The goal is to log information about which closures are evaluated where. This
information is not exposed in the UI yet, but will be needed to be able to debug
the evaluation and inspect socket values within closures.
Pull Request: https://projects.blender.org/blender/blender/pulls/137351
The `GeoTreeLog::ensure_evaluated_gizmo_nodes()` reran the iteration
over the tree loggers to add the node ids for the evaluated gizmo.
This wasn't an issue because `GeoTreeLog::evaluated_gizmo_nodes` is
a set, so nothing changed when trying to re-add the same ids.
This sets `reduced_evaluated_gizmo_nodes_` to `true` (probably an
oversight when this got added) so that the function returns early when
called again.
The `Group ID` input on every node is a hidden value except for the
Accumulate Field node. This patch just hides that value to bring it
inline with the other nodes, as different single values are meaningless.
Pull Request: https://projects.blender.org/blender/blender/pulls/137160
The nodes from #134640 were initially built off the Accumulate Field node.
During review for those nodes, certain changes to the code were suggested.
This patch applies the same changes to Accumulate Field node.
These changes namely being:
- Use `std::move` for field inputs
- Use `std::nullopt` as default for `node_type_from_other_socket`
Pull Request: https://projects.blender.org/blender/blender/pulls/137209
The main goal here is to add `GeoTreeLogger.tree_orig_session_uid`. Previously,
it was always possible to derive this information in `ensure_node_warnings`.
However, with closures that's not possible in general anymore, because the
Evaluate Closure node does not know statically which node tree the closure zone
is from that it evaluates. Therefore, this information has to be logged as well.
This patch initializes `tree_orig_session_uid` the same way it initializes
`parent_node_id`, by scanning the compute context when creating the tree logger.
To make this work properly, some extra contextual data had to be stored in some
compute contexts.
This is just a refactor with no expected functional changes. Node warnings for
closures are still not properly logged, because that requires storing
source-location data in closures, which will be implemented separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/137208
`BLI_assert(b[i] != T(0));` assert in `VecBase operator/(const VecBase &a, const VecBase &b)`. Not an issue in release mode because the result of `math::length(x/0)` evaluates to zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/137203
The original motivation for this was to prepare the API to support having more
than one tree log for each zone. Currently, there is always a well defined tree
log for each zone (when the inspection index is taken into account). However,
for closures that is less true and there may be more than one equaly valid tree
log. While we might still want to show only one value per socket initially, it
would probably be nice in the future to support accessing information from
multiple evaluations at the same time (also for loops).
None of this is implemented here though, it's just a refactor with no expected
functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/137166
Adds field versions of the operations from Attribute Statistic, can
support grouping via Group IDs. These operations are added as separate
nodes: `Field Average`, `Field Min & Max`, & `Field Variance` which
group the different statistic operations according to their use.
Supported Data Types:
- Field Average - (Float, Vector)
- Field Min & Max - (Float, Integer, Vector)
- Field Variance - (Float, Vector)
Pull Request: https://projects.blender.org/blender/blender/pulls/134640
