The Lens Distort node is different between CPU and GPU when jitter is
enabled. That's because GPU incorrectly assumed that jitter with no
dispersion would have no effect. So we fix this by adjusting the
identity condition.
Further more, the green channel was not jittered for the GPU, that's
because the jitter was only seeded by the integration steps and was thus
constant for all channels. And since the green channel is the result of
addition of two opposite accumulations, the green channel was left
unaltered. To fix this, we include the start channel of the integration
in the seed to the jitter to make sure different channels get different
jitter.
Pull Request: https://projects.blender.org/blender/blender/pulls/126993
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
This patch supports the viewer node in the new CPU compositor. To do
that, the context viewer output mechanism was refactored to allow CPU
storage by utilizing the result class as opposed to a GPU texture.
This patch adds support for CPU side buffers for the result class. A new
storage type member was added to identify the type of buffer storage,
and allocation will either allocate a GPU texture or a CPU buffer based
on the context's GPU usage.
This patch allows the result to be allocated using new textures as
opposed to using pooled texture. This is useful to allow the result
class to be used for persistent data like cached resources which can't
be pooled since it spans multiple evaluations.
Temporary results are essentially results with a default reference count
of 1, so we default to 1 for all results and set the initial reference
count differently as need.
The File Output node doesn't provide an option to save byte formats like
PNG in a space that is not sRGB. This is problematic for data images
like normal maps, which need to be saved as non-color.
This patch adds a Color Space option to the File Output node to allows
users to override the assumed color space. This also adds a new global
Save As Render option that is used if Use Node Format is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124238
The newly added viewport compositor was missing a try-catch guard around
the OCIO `getProcessor` call. All prior call sites were protected except
this one. Unhandled exceptions can occur if the user tries to use a
colorspace config that is not present in their OCIO configuration.
The surrounding code paths need some work in order to not crash at a
later point, which would also impact builds with no OCIO support at all.
In the case of no OCIO support at all, a warning label is placed on the
node as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/125526
This patch adds support for multi-pass compositing for EEVEE. This is
done by copying the passes used by the compositor node tree to the DRW
view data, which can then be accessed by the viewport compositor.
The viewport compositor will fallback to the viewport texture or an
invalid output of the passes were not initialized, this is currently the
case for any render engine that is not EEVEE.
A future optimization that we can do is eliminate the film pass copy
shaders and only copy the data that EEVEE rendered, which can be a
subset of the viewport for border rendering. This is not done at the
moment because not all engines support passes at the moment, so the
compositor expects full viewport passes.
Depends on: #123685, #123817, #123815.
Pull Request: https://projects.blender.org/blender/blender/pulls/123378
The Cryptomatte node makes the UI very slow in Image mode. That's
because the node updates its available Cryptomatte layers on every
redraw, which is a blocking operation that is not very fast.
To fix this, we only update the layers when engine layers change for
the Scene mode, and when image settings change for Image mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/124738
Cryptomatte layer initialization required the active scene to update the
image user frame, but the image user is already updated through other
mechanisms and is thus redundant to do at draw time, so we remove the
frame update call as well as the scene argument from the call chain. The
frame number of the image user is ignored at compositing time in any
case since it is set to the compositing scene frame.
This is needed for #124738.
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
This adds a new mode to the Color Balance node, which applies a white point
transformation similar to the one applied in the view transform.
Unlike the view transform, the compositor node allows specifying both the
source and the destination white point for more flexibility. Both default
to the D65 white point, so just leaving the destination alone achieves the
same behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/124110
The vector pass and potentially other vectors that store 4 values are
stored wrongly, in particular, the last channel is ignored. To fix this
we identify if a vector pass is 4D and store the information in the
result meta data, then use this information to either save a 3D or a 4D
pass in the File Output node.
This is a partial fix for the GPU compositor only. The complete fix for
the CPU compositor will be submitted separately as it is not
straightforward and will likely require a refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124522
The Cryptomatte layers in the compositor are saved compressed and saved
in half precision in the File Output node. That's because the EXR writer
makes decision about compression and half float based on channel names.
And Cryptomatte are currently saved using RGBA channel names like other
color images.
To fix this, we follow the Cycles convention of using lowercase rgba for
Cryptomatte images, allowing them to be saved without compression and
always in full precision since they are otherwise useless.
Fixes#124208, #87988.
Pull Request: https://projects.blender.org/blender/blender/pulls/124508
This patch adds support for meta data in the GPU compositor much like
the mechanism that already exist in the CPU compositor. Only Cryptomatte
meta data is handled at the moment because that is the only meta data
that the compositor supports.
The is_data member of the result was moved to the meta data structure for
consistency with the CPU compositor.
Fixes#124222.
Pull Request: https://projects.blender.org/blender/blender/pulls/124460
This patch supports the Cryptomatte picker in the 3D viewport. Instead
of picking a color from the viewport GPU texture, we instead sample the
scene directly to get the object or material under the cursor, then hash
their names to get the Cryptomatte hash value. We do this because the
viewport texture have limited precision, so it can't store the
Cryptomatte hash values.
Additionally, we adjust the Cryptomatte session code to extract the
Cryptomatte manifest from the scene directly, as opposed to the
RenderResult. This is done to make it work even when no RenderResult
exist, as is the case for the viewport compositor, which is needed
especially after #123378.
Pull Request: https://projects.blender.org/blender/blender/pulls/123815
The Bloom mode of the Glare node crashes if the input image is too
small. This is because bloom is computed using a down-sampling followed
by an up-sampling chain, and if the user supplied size is not maximum,
the computed chain length might be zero or negative, which is not
handled gracefully. To fix this, we just sanitize the chain length.
Pull Request: https://projects.blender.org/blender/blender/pulls/124089
Currently, the Render mode of the GPU Cryptomatte mode extracts the
Cryptomatte layers based on information in the RenderResult of the
scene. This means the node will not work if no RenderResult exists,
which is typically the case for the viewport compositor, and especially
after #123378.
To fix this, we simply acquire the passes directly from the appropriate
view layer based on the node's layer name. The render compositor context
implementation will handle the extraction from the RenderResult, while
the viewport compositor will just return the DRW passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123817
The File Output node ignores color space overrides for EXR images. To
fix this, we save the images using save_as_render set to true. We don't
need to provide this as an option similar to other image types because
even when save_as_render is set to true, it will not have an effect
unless the user chooses to override the color space explicitly, since it
is not affected by view transforms and the like.
Pull Request: https://projects.blender.org/blender/blender/pulls/122791
The File Output node forces all inputs to have the same size, which
should only be the case for multilayer files. This is a regression in
931c188ce5. To fix this, we allow inputs to have any size, except for
multilayer files, which are realized on the automatic operation domain
of the operation.
Pull Request: https://projects.blender.org/blender/blender/pulls/122824
The Glare node shifts the color of the highlights when the threshold is
high. That's because the thresholding algorithm simply subtracts the
threshold from the RGB data, which is not expected to retain the same hue
of the color.
To fix this, we do the thresholding only on the luminance of the color
in HSV color space. This eliminates the color shifting and also helps to
smooth the edges of the highlights.
This is a breaking change, but it is more of a fix rather than a change
of behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/122570
Remove the button "Update Views" that requires the user to update visible views manually. This is now consistent with the automatic update of compositor tree, when views are added or deleted, see #120685.
The patch also addresses #109866 (not really a fix since behavior in that bug report is intentional).
Pull Request: https://projects.blender.org/blender/blender/pulls/122290
This patch adds support for timing GPU compositor executions. This was
previously not possible since there was no mechanism to measure GPU
calls, which is still the case. However, since 2cf8b5c4e1, we now flush
GPU calls immediately for interactive editing, so we can now measure the
GPU evaluation on the host, which is not a very accurate method, but it
is better than having no timing information. Therefore, timing is only
implemented for interactive editing.
This is different from the CPU implementation in that it measures the
total evaluation time, including any preprocessing of the inputs like
implicit type conversion as well as things like previews.
The profiling implementation was moved to the realtime compositor since
the compositor module is optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/122230
The issue originates to the change in default view transform from Filmic
to AgX, which does slightly different clipping, and clips color to black
if there is any negative values.
This change implements an idea of skipping view transform for viewer
node when it is connected to the Pick output of the cryptomatte node.
It actually goes a bit deeper than this and any operation can tag its
result as a non-color data, and the viewer node will respect that.
It is achieved by passing some extra meta-data along the evaluation
pipeline. For the CPU compositor it is done via MetaData, and for the
GPU compositor it is done as part of Result.
Connecting any other node in-between of viewer and Cryptomatte's Pick
will treat the result as color values, and apply color management.
Connecting Pick to the Composite output will also consider it as color,
since there is no concept of non-color-managed render result.
An alternative approaches were tested, including:
- Doing negative value clamping at the viewer node.
It does not work for legacy cryptomatte node, as it needs to have
access to original non-modified Pick result.
- Change the order of components, and store ID in another channel.
Using one of other of Green or Blue channels might work for some view
transforms, but it does not work for AgX.
Using Alpha channel seemingly works better, but it is has different
issues caused by the fact that display transform de-associates alpha,
leading to over-exposed regions which are hard to see in the file from
the report. And might lead to the similar issues as the initial report
with other objects or view transforms.
- Use positive values in the Pick channel.
It does make things visible, but they are all white due to the nature
of how AgX works, making it not so useful as a result.
Pull Request: https://projects.blender.org/blender/blender/pulls/122177
This patch implements the Fog Glow Glare node by porting the CPU
implementation, so it is not GPU accelerated and is not expected to be
realtime. However, after d4bf23771d, it is now fast enough to be usable,
see that commit for more information on the implementation.
The only difference is that the kernel part of the convolution is cached
in the realtime compositor, so it should be about 30% faster than CPU
for interactive editing.
In the future, this implementation will be replaced by a proper GPU
implementation, likely based on VkFFT.
The Sun Beams node produces NaNs when the ray length option is zero.
This is due to zero division in the code, which we avoid by skipping
computation altogether when the ray length is zero.
This patches optimizes the Fog Glow Glare node to be about 25x faster
for 4K images. This is mainly achieved by utilizing the FFTW library and
multi-threading support code. Further improvements are still possible by
caching kernels, but the CPU compositor does not support caching yet.
The old Hartley transform was removed, so the node no longer works when
FFTW is disabled as a build time option, much like the OIDN node. A new
BLI library was introduced for FFTW, it includes some helper routines
relevant for FFTW as well as an initialization routine that sets up
multithreading using TBB as well as thread safety.
Build system support for threaded FFTW was also added, which defines the
relevant variables to detect threading support as well as add the
relevant libraries.
We do not currently have the threaded FFTW libs in our precompiled libs,
so the threading code is disabled until the libs lands in the coming
weeks. So currently, the code is only about 9x faster.
The only functional change is that the kernel is now odd sized, which
should produce more accurate results, but the final result is almost
identical and mostly undetectable.
The plan is to port this to the GPU as well similar to how we implement
OIDN until we have a GPU FFT implementation. GPU compositor can also do
caching, so it should be faster, being able to compute a 4K image in
under half a second.
Pull Request: https://projects.blender.org/blender/blender/pulls/121653
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
This allows setting a color tag for node groups which affects the header
color of group nodes. With this, node groups can look even more similar
to built-in nodes. The only remaining difference is the node group icon in
the node header.
Blender has quite a few different built-in color tags. Most of those are
exposed with very few exceptions. For example, the layout, interface
and pattern categories are not exposed because they are only for built-in
nodes or are not used anymore.
It's generally agreed upon that the set of different color tags is likely too
large. Some differences between color make more sense in some contexts
than in others. In the interest of consistency, it was decided to expose all
these categories anyway. If we ever decide to consolidate them, the worst
that can happen is that a group looses it's category, which wouldn't be too bad.
Pull Request: https://projects.blender.org/blender/blender/pulls/121385
This allows node groups to have a description that is shown in the add menu
or when hovering over the node header.
This new description is stored in `bNodeTree.description`. Unfortunately, it
conflicts a bit with `ID.asset_data.description`. The difference is that the latter
only exists for assets. However, it makes sense for node groups to have
descriptions even if they are not assets (just like `static` functions in C++ should
also be able to have comments). In some cases, node groups are also generated
by addons for a specific purpose. Those should still have a description without
being reusable to make it easier to understand for users.
The solution here is to use the asset description if the node group is an asset,
and to use `bNodeTree.description` otherwise. The description is synced
automatically when marking or clearing assets.
A side benefit of this solution is that appended node group assets can keep their
description, which is currently always lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/121334
This patch implements the Fast Gaussian blur mode for the Realtime
Compositor. This is a faster but less accurate implementation of
Gaussian blur.
This is implemented as a recursive Gaussian blur algorithm based on the
general method outlined in the following paper:
Hale, Dave. "Recursive gaussian filters." CWP-546 (2006).
In particular, based on the table in Section 5 Conclusion, for very low
radius blur, we use a direct separable Gaussian convolution. For medium
blur radius, we use the fourth order IIR Deriche filter based on the
following paper:
Deriche, Rachid. Recursively implementating the Gaussian and its
derivatives. Diss. INRIA, 1993.
For high radius blur, we use the fourth order IIR Van Vliet filter based
on the following paper:
Van Vliet, Lucas J., Ian T. Young, and Piet W. Verbeek. "Recursive
Gaussian derivative filters." Proceedings. Fourteenth International
Conference on Pattern Recognition (Cat. No. 98EX170). Vol. 1. IEEE,
1998.
That's because direct convolution is faster and more accurate for very
low radius, while the Deriche filter is more accurate for medium blur
radius, while Van Vliet is more accurate for high blur radius. The
criteria suggested by the paper is a sigma value threshold of 3 and 32
for the Deriche and Van Vliet filters respectively, which we apply on
the larger of the two dimensions.
Both the Deriche and Van Vliet filters are numerically unstable for high
blur radius. So we decompose the Van Vliet filter into a parallel bank
of smaller second order filters based on the method of partial fractions
discussed in the book:
Oppenheim, Alan V. Discrete-time signal processing. Pearson Education
India, 1999.
We leave the Deriche filter as is since it is only used for low radii
anyways.
Compared to the CPU implementation, this implementation is more
accurate, but less numerically stable, since CPU uses doubles, which is
not feasible for the GPU.
The only change of behavior between CPU and this implementation is that
this implementation uses the same radius, so Fast Gaussian will match
normal Gaussian, while the CPU implementation has a radius that is 1.5x
the size of normal Gaussian. A patch to change the CPU behavior #121211.
Pull Request: https://projects.blender.org/blender/blender/pulls/120431
The compositor used to have a feature that would calculate tiles for the viewer based on a custom order. Since the removal of the tile based compositor, this code is unused.
Pull Request: https://projects.blender.org/blender/blender/pulls/121176
The compositor execute functions have a `rendering` argument to specify
if the compositor is executing as part of the render pipeline. But the
render context argument is null if we are not rendering, so the
`rendering` arguement is redundant and can be removed.
Additionally, we no longer use use_file_output as a hack to detect
rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/120659
Extract
- Statuses for the external text editor
- Newly created enum node item
- Newly created plane track data
- Newly created custom orientation data
- Operator names in drag and drop menu (need to use operator's
translation context)
- GN attribute statistic node inputs
Disambiguate
- Single-letter colors: A and B can mean Alpha and Blue, or simply A
and B as in two operands in an operation
- Dissolve: issue reported by Tamar Mebonia in #43295
- Translate in the User Preferences. This introduces a new
BLT_I18NCONTEXT_EDITOR_PREFERENCES ("Preferences") translation
context
- Planar (reported by deathblood)
This one is incomplete, because there is currently no way to
disambiguate presets or GN fields. I don't see how either could be
achieved cleanly.
The former would need to define the context inside the preset and
evaluate the file prior to showing it in the presets menu, which
sound bad.
The latter would need to introduce an additional string inside
`FieldInput`s, which would be controversial given how little it
would be used.
Remove
- Unused translation `iface_("%s")` in toolbar
- Remove obsolete N_() tags in a few node descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/119065
