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
Adds a new node to set the Grease Pencil depth ordering.
Here are the options:
* 2D Layers: Uses the Layer order + Stroke order to calculate the depth ordering.
* 3D Location: Uses the 3D position of the points as the depth.
This reflects the same setting that is available in the Grease Pencil
object-data properties.
The node is added to the `Grease Pencil` > `Write` menu.
Resolves#129458.
Pull Request: https://projects.blender.org/blender/blender/pulls/135914
Adds a new `Set Grease Pencil Color` node.
It was already possible to write to the color and opacity attributes using the
`Store Named Attribute` node, but this required the user to know the names
of the "built in" attributes.
Similar to how we can set other built-in attributes (e.g. the curve radius) this
adds a node to write to the following Grease Pencil attributes:
* `vertex_color` (point domain): The color of a point (the alpha value is used
as a mix factor with the base material color).
* `opacity` (point domain): The opacity of a point.
* `fill_color` (curve domain): The fill color of a stroke (the alpha value is used
as a mix factor with the base material color).
* `fill_opacity` (curve domain): The fill opacity of a stroke.
For consistency with other nodes, there is a mode to switch between writing
to the points (`Stroke` mode) and the fills (`Fill` mode).
Pull Request: https://projects.blender.org/blender/blender/pulls/136260
Add a "dumb vector" storage option for custom normals, with the
"custom_normal" attribute. Adjust the mesh normals caching to
provide this attribute if it's available, and add a geometry node to
store custom normals.
## Free Normals
They're called "free" in the sense that they're just direction vectors
in the object's local space, rather than the existing "smooth corner
fan space" storage. They're also "free" in that they make further
normals calculation very inexpensive, since we just use the custom
normals instead. That's a big improvement from the existing custom
normals storage, which usually significantly decreases
viewport performance. For example, in a simple test file just storing
the vertex normals on a UV sphere, using free normals gives 25 times
better playback performance and 10% lower memory usage.
Free normals are adjusted when applying a transformation to the entire
mesh or when realizing instances, but in general they're not updated for
vertex deformations.
## Set Mesh Normal Node
The new geometry node allows storing free custom normals as well as
the existing corner fan space normals. When free normals are chosen,
free normals can be stored on vertices, faces, or face corners. Using
the face corner domain is necessary to bake existing mixed sharp and
smooth edges into the custom normal vectors.
The node also has a mode for storing edge and mesh sharpness, meant
as a "soft" replacement to the "Set Shade Smooth" node that's a bit
more convenient.
## Normal Input Node
The normal node outputs free custom normals mixed to whatever domain is
requested. A "true normal" output that ignores custom normals and
sharpness is added as well.
Across Blender, custom normals are generally accessed via face and
vertex normals, when "true normals" are not requested explicitly.
In many cases that means they are mixed from the face corner domain.
## Future Work
1. There are many places where propagation of free normals could be
improved. They should probably be normalized after mixing, and it
may be useful to not just use 0 vectors for new elements. To keep
the scope of this change smaller, that sort of thing generally isn't
handled here. Searching `CD_NORMAL` gives a hint of where better
propagation could be useful.
2. Free normals are displayed properly in edit mode, but the existing
custom normal editing operators don't work with free normals yet.
This will hopefully be fairly straightforward since custom normals
are usually converted to `float3` for editing anyway. Edit mode
changes aren't included here because they're unnecessary for the
procedural custom normals use cases.
3. Most importers can probably switch to using free normals instead,
or at least provide an option for it. That will give a significant
import performance improvement, and an improvement of Blender's
FPS for imported scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132583
Some nodes like the Math and Mix Color node are duplicated when looking
at the link add search menu. That's because all nodes are considered in
that operation, even ones that are not listed in the menu. To fix this,
just disable the functionality for those legacy nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/136979
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
In several nodes such as the capture attribute, bake, simulation, repeat,
and For Each nodes, we already use alignment of input and output sockets
to show when they correspond, make better use of space, and simplify
the UI. This PR extends that change to many more nodes. Sockets are
aligned when they have the same name and data propagates between
them. For now the various "sampling" nodes like Raycast and Sample
Nearest Surface are left out since their interface is a bit more complex.
Backward and forward compatibility aren't affected by this change;
it's just visual.
Pull Request: https://projects.blender.org/blender/blender/pulls/135876
This patch adds a new interpolation option to the Scale node to control
how pixels are sampled during scaling. For constant sizes, this stores
the interpolation for later realization, while for variable sizes, the
interpolation takes effect immediately.
Pull Request: https://projects.blender.org/blender/blender/pulls/135989
