Currently UI code always has to use char pointers when interacting with
the translation system. This makes benefiting from the use C++ strings
and StringRef more difficult. That means we're leaving some type safety
and performance on the table. This PR adds StringRef overloads to the
translation API functions and removes the few calls to `.c_str()` that
are now unnecessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/133887
This patch refactors the Result class in the compositor to use
GMutableSpan and std::variant to wrap the result's data. This reduces
the complexity of the code and slightly optimizes performance. This will
also make it easier to add new types and interface with other code like
multi-function procedures.
Pull Request: https://projects.blender.org/blender/blender/pulls/134112
User may think of the `radius` vector value as RGB color, however it's
meant to be the depth of scattering for R/G/B channels. Now clarified in
the desctiption.
Pull Request: https://projects.blender.org/blender/blender/pulls/134088
It already doesn't work in a very fairly simple case when the Grease Pencil
geometry is transformed. This simple case used to work before we changed
the Transform Geometry node to transform layers instead of points.
Pull Request: https://projects.blender.org/blender/blender/pulls/134131
The issue was that the code did not handle input sockets that are fields
implicitly correctly. It just retrieved a single from them, instead of
treating them as having an unknown value.
The new Object and Collection constant geometry nodes do not register their dependency on their targets.
This causes the graph not to update properly when they are modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/133784
The File Output node sometime ignores the transformations of their
inputs. That's due to the fact that transforms are now delayed and the
File Output node does not realize its inputs on its domain in case it
was not multi-layer.
To fix this, add another realization mode for transforms only. And use
that in the File Output node, as well as the Bokeh Blur, UV Map, and
Plane Track Deform, which also need this fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/133850
There is a special case in the compositor code where viewer nodes are
treated as composite nodes. This patch renames relevant methods and
updates comments to clarify this use case.
Pull Request: https://projects.blender.org/blender/blender/pulls/133811
This patch changes how the Wrap option in the Translate node works. It
now repeats infinitely when realized, and not just in its own domain.
This is essentially how it used to work prior to version 4.2, so we are
reverting that change. We also rename Wrap to Repeat for clarity.
This is part of an ongoing to project to allow the user to control how
boundaries and empty areas are filled after transformations. So similar
options will be added to all transform nodes. But this patch is the
first step, since the functionality is already there, we just need to
extend it to work in all domains.
Pull Request: https://projects.blender.org/blender/blender/pulls/133766
Artists often want to quickly switch back and forth between two or more nodes while compositing.
This patch implements two operators `NODE_OT_viewer_shortcut_set` and `NODE_OT_viewer_shortcut_get` that allow users to map a viewer node to a shortcut. For example, pressing `cltr+1` while a node is selected, assigns that node to the shortcut `1`, creates a viewer node if it has none attached and sets that viewer node to active. Pressing `1` will set the active node with shortcut `1` to active.
Shortcuts are saved in DNA to preserve them after saving/loading blend files.
Limitations:
- Only compositor node tree is supported, because shading editor has no viewer node and geometry nodes viewer works differently.
Pull Request: https://projects.blender.org/blender/blender/pulls/123641
Previously, there was a `StringRef.copy` method which would copy the string into
the given buffer. However, it was not defined for the case when the buffer was
too small. It moved the responsibility of making sure the buffer is large enough
to the caller.
Unfortunately, in practice that easily hides bugs in builds without asserts
which don't come up in testing much. Now, the method is replaced with
`StringRef.copy_utf8_truncated` which has much more well defined semantics and
also makes sure that the string remains valid utf-8.
This also renames `unsafe_copy` to `copy_unsafe` to make the naming more similar
to `copy_utf8_truncated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133677
The Translate node is a transform operation that should not realize the
transformations of its input. So this patch marks its input accordingly.
Additionally, we also protect against operating on single values and
pass them without changes.
This patch introduces a new Derived Resources concept to the compositor.
Derived resources are resources that are computed from a particular
result and cached in it in case it is needed by another operation, which
can greatly improve performance in some cases at the cost of more memory
usage.
The first use case is to store denoised versions of the Denoising Albedo
and Denoising Normals passes if auxiliary pass denoising is enabled in
the denoise node. Consequently, multi-pass denoising setups where the
same auxiliary passes are used in multiple denoise nodes should be much
faster due to caching of the derived resources.
This implementation has the limitation that it can't preemptively
invalidate the cache when the derived resources are no longer needed to
free up memory. This requires a special resource tracking mechanism that
need to happen during node tree compilation, and will be submitted
later. The limitation is not significant in the particular derived
resources that is currently implemented. Since the auxiliary passes are
rarely used outside of denoising.
Fixes#131171.
Pull Request: https://projects.blender.org/blender/blender/pulls/125671
The issue is that the localized node tree has an invalid type if the linked file
is not available. So we essentially ended up with a geometry node group that
contains a group node that points to a non-geometry nodes group.
Pull Request: https://projects.blender.org/blender/blender/pulls/133650
This patch delays applying transformations until realization happens on
some other domain.
Currently, transformations are applied immediately at the point of
transform nodes, this is problematic for a few reasons:
- If that result was then realized on some other domain, interpolation
will have happened two times, at the transform nodes and at the node
that required realization, causing less than ideal precision issues.
- It is not possible to repeat or extend a rotated result because its
empty areas will be zero filled, leaving gaps in its extension. So
this patch is a prerequisite for #132371 if we want full support for
repetition.
- Doing inverse transformations will introduce interpolation artifacts
which might be undesirable. Inverse transformations might be used to
do pixelation for instance, so this change will be undesirable in this
case. But we decided that this is not a use case that we want to
support, and we added explicit pixel size control to the pixelate node
as an alternative.
So this has four implications, two that might be considered bad:
- Transformations will now be higher quality and more precise.
- Repetition and other boundary extension methods will now be possible.
- Downsampling then upsampling will no longer produce pixelated results.
- Realization might happen multiple times with identical results in some
cases.
The last point not a big issue, since domain realization is not a big
bottleneck in the compositor, and the plan is to move realization into
pixel operations, so it will even be more efficient than it is now.
Pull Request: https://projects.blender.org/blender/blender/pulls/133158
Fairly weird, debug builds were fine, but release ones with clang 19
and mold failed at linking step, complaining about misisng
`bNode::output_sockets()` symbol.
Guess debug config somehow pulls this symbol from somewhere else?
This reverts commit 19e9092cb6. The
minimum requirement is for builds that Blender officially provides. We
still need to maintain code for none SSE builds.
This bug occurs when the user deletes the rightmost stop on a
color ramp with 2 stops. After doing this, the color ramp appears
to stop updating its results.
This bug is due to a shader optimization for color ramps. For ramps
with 2 stops or less, the first and second stops are hardcoded as
inputs to get the results of the color ramp. When deleting the
rightmost stop, the stop's data isn't actually changed. The ramp
just updates its total stop number. Because of this, the result of
the color ramp won't change.
This is fixed by only allowing this optimization when a ramp has
exactly 2 stops. This solution works well since it keeps color ramp
code neat and concise. It also makes more logical sense to only allow
this optimization to work with 2 stops since it uses 2 hardcoded values
from the color ramp. It's also unlikely this will lead to adverse
performance problems since it doesn't make sense to use a color ramp
with 1 color stop. In that case, the user should just use an RGB node.
Another possible solution for this problem would be to update the data
for the second stop in the color ramp to exactly match the first when
deleting the second stop. However, this is undesirable since the code
wouldn't make much sense to those who don't know about the color ramp
optimizations.
Pull Request: https://projects.blender.org/blender/blender/pulls/132951
Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
Note the RBG to BW node implementation is used for implicit conversions,
so that is covered as well.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
This builds on top of 80441190c6 to gray output
unused inputs of the Mix and Mix Shader node. These nodes have unused inputs if
their mix factor is 0 or 1 (+ some special cases for non-uniform vector mixing
and blend modes).
Pull Request: https://projects.blender.org/blender/blender/pulls/133369
This patch automatically grays out input values which can't affect the output
currently. It works with inputs of group nodes, geometry nodes modifiers and
node tools.
To achieve this, it analyses the node tree and partially evaluates it to figure
out which group inputs are currently not linked to an output or are disabled by e.g.
some switch node.
Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874
Related info in blog post:
https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility
Follow up task for designing a UI that allows hiding sockets: #132706
Limitations:
* The inferencing does not update correctly when a socket starts being
animated/driven. I haven't found a good way to invalidate the cache in a good
way reliably yet. It's only a very short term problem though. It fixes itself
after the next modification of the node tree and is only noticeable when
animating some specific sockets such as the switch node condition.
* Whether a socket is grayed out is not exposed in the Python API yet. That will
be done separately.
* Only a partial evaluation is done to determine if an input affects an output.
There should be no cases where a socket is found to be unused when it can actually
affect the output. However, there can be cases where a socket is inferenced to be used
even if it is not due to some complex condition. Depending on the exact circumstances,
this can either be improved or the condition in the node tree should be simplified.
Pull Request: https://projects.blender.org/blender/blender/pulls/132219
Previously, when evaluated on the face corner domain, the normal input
node just returned the face normals, as if the mesh was completely flat
shaded. This ignores face and edge smoothness, and custom face corner
normals. In the past couple years the expected behavior of accessing
normals has become much clearer and this behavior is clearly a mistake
in retrospect.
This commit exposes the same face corner normals used everywhere else
in Blender when the node is evaluated on the corner domain. The old
behavior is accessible with a node property in the sidebar. There is
versioning so old files have the property set and get the same results.
This is split from !132583.
Pull Request: https://projects.blender.org/blender/blender/pulls/133340
