This patch refactors the ShaderNode class to be a concrete class that
is implemented in terms of the node type gpu_fn. This is done to make it
easier to reuse existing nodes in other parts of Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/134210
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
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
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
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 uses the following accessor methods in more places in more places:
`is_group()`, `is_group_input()`, `is_group_output()`, `is_muted()`,
`is_frame()` and `is_reroute()`.
This results in simpler code and reduces the use of `bNode.type_legacy`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132899
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
This patch normalizes the Bloom output to be more energy conserving and
in a reasonable range. This is essentially constructed such that the
impulse response to a constant input maintains the same input.
The reason why Bloom has a very high range is because it accumulates a
downsampling chain without any sort of attenuation, so the final result
can be quite large. EEVEE fixed that by making the Strength range in the
[0, 0.1] range, so users who are used to that range think the default
value of a unit Strength in the glare node is large and hard to work
with. Hence the need for this patch.
The normalization factor is simply the length of the chain, since for a
constant input, all chain images will have the same constant input.
We need to version this change in a similar manner to how the glare node
was versioned in 004e3d39fa, where the scene render size is assumed. We
also assume the inputs are not connected, because they were turned into
inputs just last week, so we needn't worry about that case.
This is a partial implementation of #124176 to address #131325.
Pull Request: https://projects.blender.org/blender/blender/pulls/133037
This patch reorganizes the Glare node inputs into panels, grouped by the
function they perform. The panels are:
- Highlights: Which are inputs related to highlights extraction.
- Adjust: Which are inputs that adjusts the generated glare.
- Glare: Which are glare type specific inputs.
Additionally, the Threshold parameter was assigned a more unique
identifier to be more future proof and consistent with other inputs, and
the descriptions of some inputs were updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/132993
This patch adds two new inputs to the Glare node, Highlights Smoothness
and Max Highlights. Smoothness allows the user to control how smooth the
highlights are after thresholding and Max allows the user to suppress
very high brightness pixels.
Those are essentially similar to the Knee and Clamp options in old EEVEE
bloom, though they work differently.
The issue with the Knee parameter in old EEVEE bloom, aside from being
named after a body part, is that it actually isn't smooth or continuous
around zero if the threshold is sufficiently close to zero relative to
the Knee parameter. That's because zero lies in the smoothing kernel
region in those cases, and since zero pixels becoming highlights is very
bad, EEVEE just returned zero as a special case for zero brightness, but
values like 0.0001 will be full blown highlights.
The new nicely named Smoothness input uses adaptive smoothing such that
the smoothing kernel size will be reduced as the threshold nears zero,
such that smoothed highlights will be continuous and smooth around zero.
The Max Highlights input is similar to clamped, it it suppresses very
bright highlights such that their brightness doesn't exceed the
specified max.
This is a partial implementation of #124176 to address #131325.
Pull Request: https://projects.blender.org/blender/blender/pulls/132864
Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
This removes the second to last usage of `NOD_static_types.hh` which we intend
to remove. A nice benefit is that the idname is now finally more explicit when a
node is registered. Previously it was difficult to search for the definition of
a node in the code when one had only the idname, which is the main identifier
for nodes.
The main change is in `node_type_base`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132815
As part of an effort to remove this header, reducing the need for macro/
include magic and making node definitions more independent, move
the node UI name and description definitions to each node's file.
The UI name, description, and idname are also moved to std::string
instead of char arrays.
Similar to b43e2168e3.
Pull Request: https://projects.blender.org/blender/blender/pulls/132708
Make the type structs non-trivial, use new and delete for allocation and
freeing, and use std::string for most strings they contain. Also use
StringRef instead of char pointers in a few places. Mainly this improves
ergonomics when working with the strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/132750
This patch moves wrapped translation from a special case of the general
transform algorithm to the Translate node. Since the Translate node is
the only user of this special case, it doesn't make sense to complicate
a generate algorithm with it. This will make future refactors of this
code easier.
Pull Request: https://projects.blender.org/blender/blender/pulls/132793
This patch redesigns the Glare node to improve the user experience. The
improvements are as follows.
Two new outputs were added, Glare and Highlights. The Glare output gives
the generated glare without the input, and is useful when the user wants
to adjust the glare before adding it to the image. The Highlights output
gives the areas that are considered highlights when computing the glare,
and is useful if the user wants to temporally check the highlights while
doing adjustments or wants to use those as a base for creating a custom
glare setup.
The Mix node option was removed and a new Strength single value input
was added to serve the same functionality. The Mix option had a range of
[-1, 1], where the [-1, 0] sub-range essentially controlled the strength
of the glare, 0 being full strength and -1 being zero strength. While
the [0, 1] range returned the generated glare with an attenuated version
of the image added, that is, it was useless except for the value of 1,
which returned the generate glare only.
Aside from being a very intuitive range, it also meant that the power of
glare can't be boosted beyond the full strength of, you guessed it, 0.
The newly added Strength input has a soft range of [0, 1] and can be
boosted beyond 1. If the users want the glare only, they can use the
newly provided Glare output.
The Size node option used for Bloom and Fog Glow was removed and a new
Size single value input was added. The Size node option had yet another
very intuitive range of [1, 9], and it was related exponentially to the
actual size of the Glare. For Bloom, the actual bloom size relative to
the image was 2^(Size-9), so a Size of 8 means the bloom covers half of
the image. For Fog Glow, the actual bloom size in pixels is 2^Size, so
the glare size is not relative to the image size and would thus change
as the image resolution change. Furthermore, the maximum possible glare
size was 512 pixels, and the user couldn't make fine adjustments to the
size.
The newly added Size input has a range [0, 1], where 1 means the glare
covers the entire image, 0.5 means it covers half the image, and so on.
That means it is consistent between Bloom and Fog Glow, it is relative
to the image size, it allows as large of a glare as possible, it is
continuous for Fog Glow, but not for Bloom because that requires an
algorithmic change that will be implemented separately.
The Threshold, Streaks, Streaks Angle, Iterations, Fade, and Color
Modulation node option was turned into a single value node input to
allow the option to be used in node groups.
---
Versioning was added to transfer node options into sockets, but it is
not all 1:1 versioning, since the old Size option was not relative to
the image size, so it depends on runtime information of the input size.
As a guess, we assume the render size in that case. Versioning the
[0, 1] range of the Mix option intentionally omits the attenuation of
the image input, because that is almost certainly not what the user
wants and was probably done thinking it controls the strength.
Glare code now sets the alpha channel to 1, that's because it was
already ignored in the mixing step, but now that we expose the Glare
output, we need to set it to 1. So this is not a functional change.
The get_glare_size() method was renamed for clarity since it now
conflicts with the newly added Size input.
---
This is a partial implementation of #124176 to address #131325. In
particular, it adjust existing functionality, it doesn't add any new
ones. Those will be added in separate patches.
Pull Request: https://projects.blender.org/blender/blender/pulls/132499
This patch adds support for using integer sockets in compositor nodes.
This involves updating the Result class, node tree compiler, implicit
conversion operation, multi-function procedure operation, shader
operation, and some operations that supports multiple types.
Shader operation internally treats integers as floats, doing conversion
to and from int when reading and writing. That's because the GPUMaterial
compiler doesn't support integers. This is also the same workaround used
by the shader system. Though the GPU module are eyeing adding support
for integers, so we will update the code once they do that.
Domain realization is not yet supported for integer types, but this is
an internal limitation so far, as we do not plan to add nodes that
outputs integers soon. We are not yet sure how realization should happen
with regards to interpolation and we do not have base functions to
sample integer images, that's why I decided to delay its implementation
when it is actually needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132599
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
