Previously, all information outside the render area did not get considered because transform operations such as translation and rotation might cause the output area to be smaller.
In this patch, the whole image gets flipped regardless of the output area, which makes the behavior consistent with the GPU compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/119278
Rendering with F12 causes some inconsistencies between canvases and areas of interest. This is due to some corrections of composite node canvas to fit to the render size, which are not necessary for the Viewer Node. This patch fixes the issue by considering the input image as a whole before translating.
Note: this is still consistent with immediate realization of transform nodes in GPU compositor, where nodes are to be evaluated from left to right.
Pull Request: https://projects.blender.org/blender/blender/pulls/119276
GPU compositor crashes when the Hue Correct and one of the Curves node
are used together. That's due to a utility function that goes by the
same name in both nodes. To fix this, rename one of them to be more
specific.
This patch implements the GPU Bloom glare for the CPU compositor, and
adds a new option for it, leaving the Fog Glow option unimplemented once
again for the GPU compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/119128
The Realtime Compositor crashes with intricate node setups. That's
due to hardware limitations where shaders can't have as many output
images as needed by the compositor shader operations. To fix this, we
recursively split shader operations until their output count fits the
hardware limitation.
Pull Request: https://projects.blender.org/blender/blender/pulls/119075
Compositor outputs are sometimes clipped. That's because consecutive
shader operations in the GPU compositor were assumed to have the same
domain. So make sure to reset the domain during compile unit resets.
Blender crashes when using the compositor debugger. That's because it
assumes the names of the operation classes will be demangled and will
proceed to slice them causing crashes. The standard makes no guarantees
about the form of the returned type_info::name, and it is implementation
defined.
While it is possible to demangle those names and return something that
is more human readable, it doesn't seem worth it as this is only used by
developers who should have no problem identifying mangled names. So we
just display the name as is.
Pull Request: https://projects.blender.org/blender/blender/pulls/118904
This patch unifies the anti-aliasing of plane deforms between the CPU
and GPU compositors. The CPU used a multi-sample approach, where the
mask was computed 8 times with a jitter, then averaged to get smooth
edges. The GPU relied on the anisotropic filtering with zero boundaries
to smooth the edges.
Furthermore, the CPU implementation ignored the anti-aliasing for the
deformed image and also relied anisotropic filtering like the GPU, so
its outputs were different.
To unify both implementation, we use the existing SMAA anti-aliasing
algorithm instead, and use the anti-aliased mask for the image output as
well. This affects both the Corner Pin and Plane Deform nodes.
A consequence of this change for the Plane Deform node is that motion
blur will appear to have less samples, that's because it was sampled
8-times more in the previous implementation. But users can just increase
the samples in the node to account for that.
Pull Request: https://projects.blender.org/blender/blender/pulls/118853
This patch unifies the variable size blur between the CPU and GPU
compositor. The difference is due to how weights are computed and used.
The CPU computed a nested array of weights for every possible size, that
is, from size 1 to the base size. Then, it assumed the kernel was
separable and reconstructed a 2D kernel by selecting two 1D weights
array and multiplying them for every pixel of the blur window.
The GPU on the other hand computes a single quadrant of the 2D weights
kernel and sampled it directly in the blur window. We favor the GPU
implementation since it makes no assumptions about the separability of
the weights kernel and since the CPU has no performance advantage even
with the assumption in place.
Pull Request: https://projects.blender.org/blender/blender/pulls/118834
Currently, the CPU compositor smoothes its input size in variable size
mode. It is unclear why this is the case, but it seems the logic is that
sharp transitions in the size input are undesirable. Alternatively, this
is similar to the morphological blurring step in the Defocus node. But
it does not use standard weights and it is not morphological in nature
at all.
This patch removes the smoothing step and uses the original size
provided by the user. Looking at resources online, it seems users almost
always expect the size inputs to be used directly, so there is no reason
for force smooth their inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/118757
New ("fullframe") CPU compositor backend is being used now, and all the code
related to "tiled" CPU compositor is just never used anymore. The new backend
is faster, uses less memory, better matches GPU compositor, etc.
TL;DR: 20 thousand lines of code gone.
This commit:
- Removes various bits and pieces related to "tiled" compositor (execution
groups, one-pixel-at-a-time node processing, read/write buffer operations
related to node execution groups).
- "GPU" (OpenCL) execution device, that was only used by several nodes of
the tiled compositor.
- With that, remove CLEW external library too, since nothing within Blender
uses OpenCL directly anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/118819
Blender would crash if the input of the Classic Kuwahara node is
translated. This is due to an out of bound access due to the miss-use of
IndexRange, where it was assumed to have a start-end constructor, while
it was in fact a start-size one. Fix this by computing the size from the
area and supplying it to the constructor.
This patch unifies the Keying node between the CPU and GPU. The
difference was due to imprecision when computing pixel saturation in the
CPU code. This typically happens when the pixel is gray-scale, and
should have a zero saturation, but it came out negative due to
imprecision. To fix this, reorder the mix expression so that the minimum
and maximum values are differenced first.
Ideally, the code shouldn't have such abrupt conditionals and should be
more robust to tiny imprecisions, but that would break the behavior and
should be evaluated separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/118625
The GPU compositor Blur node truncates the filter kernel if the blur
radius is lower than the base radius. That's because it evaluated the
filter kernel only up to the desired radius. To fix this, we evaluate
at the entire kernel for all radii using a texture sampler for the
weights.
The Viewport Compositors crashes when there are many nodes that are not
connected to the compositor or viewer outputs.
That's because those sockets were wrongly added to the shader operation,
even though they will not be used, which surpasses the limit for the
maximum image units per shader.
The CPU compositor always adds a filter for normal and albedo even if
they don't contain any data, that is, when they are not connected to
anything, by inflating a buffer with the editor value, which is not even
accesible to the user. In anycase, such a solid color will not help do
anything in the denoise operation.
This patch aligns the implementation by only adding the abeldo and
normal filter if they contain actual data, speeding up the operation in
the process.
Pull Request: https://projects.blender.org/blender/blender/pulls/118553
This patch unifies the implementation of the separable Blur operation
across CPU and GPU. The difference is due to the fact that the CPU code
ignores pixels that are across the image boundary and adjusts the
weights accordingly, while the GPU code assumes extended boundaries.
Like the rest of the Blur nodes the CPU implementation is adjusted to
assume extended boundaries until an option to change the boundary
condition is added. The alpha version of this operation will be handled
in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/118517
Currently, the Hue Correct node uses the adjusted hue when adjusting the
saturation and value of the input, so if the user adjusted the reds to
become blue, in order to change the saturation of the same area, one
would need to adjust the blues, which would overlap with the existing
blues.
This is contrary to how other compositing software like GIMP and Natron
do it, and it is less intuitive. So this patch changes the node to use
the original hue to the saturation and value curves as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/118487
The GPU Hue Correct node is slightly off due to incorrect interpolation
of curve maps. We fix this by introducing proper half-pixel offsets to
the curve map coordinates much like we do for other curve map evaluation
shaders.
The CPU and GPU implementations of the compositor Texture node sample
the texture at different locations, producing differences. This is
primarly an issue with half pixel offsets to evaluate the texture at the
center of the pixels.
The CPU compositor only adds the offsets if interpolation is disabled,
regardless if the texture is of type image or not. Further the offset
was wrong, since it was not a half pixel offset, but a full pixel one.
The offsets should always be added, since it won't make a difference in
the non interpolated case, and it should always be added especially if
interpolation is enabled. A comment in the old code mentions something
about artifacts, but it is possible that this is a consequence of the
wrong offset that was used.
This patch always adds a half pixel offset, following the GPU code.
Pull Request: https://projects.blender.org/blender/blender/pulls/118377
Currently, some compositor operations produce en empty output buffer by
specifying a COM_AREA_NONE canvas to indicate an invalid output, for
instance, when the Mask operation references an invalid mask. The
intention is that this buffer would signal that a fallback value should
fill the canvas of consumer operations.
The aforementioned behavior is currently implemented in a rather hacky
way, where it is implemented using the Translate operation as part of
canvas conversion in COM_convert_canvas, where the operation would clear
the entire buffer with zeros since out of bounds checking would always
take the out of bound case due to the empty buffer.
This behavior is problematic because we can't control the fallback
value, which would ideally be an opaque black color. Moreover, since
implicit type conversion happen before canvas conversion by design,
value typed buffers would eventually become transparent, which is rather
unexpected to the end user since float/value outputs can't have
transparency.
This is not a good design or implementation, but a redesign will be too
complex for now. So to fix this, we workaround it by handling the empty
buffer case explicitly in the Translate operation and fill the output
using a fallback black color, which works for both value and color typed
buffers, since this would also be the output of the value to color
implicit conversion.
Pull Request: https://projects.blender.org/blender/blender/pulls/118340
The File Output node crashes if it has no image input. That's because we
would be attempting to save a zero sized image. So ensure that the node
has a non zero canvas before saving anything.
This patch adds support for canceling compositor evaluations for the
realtime compositor. Only the canceling of the Denoise operation is
supported for now. That's because inter-operation canceling is not
feasible since all work will have been submitted to the GPU driver
before the user is able to cancel. So some kind of blocking operations
would need to used to actually allow canceling, which is not something
we are going to investigate as part of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117725
The compositor assumes the entire viewport as its compositing space even
in camera view. The current design decision was to limit the compositing
space by the camera region only if the camera passepartout is opaque,
that is, areas outside of the camera are not visible.
This patch changes that behavior to always limit the compositing space
by the camera region. The downside is that areas outside of the camera
will be left uncomposited.
This is useful to match viewport compositing to final render compositing
in terms of maintaining the same space, but not necessarily the same
resolution. However, this still has the limitation that space will be
different when the camera region intersects the viewport, since we only
composite their intersection in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/118241
Span is preferrable since it's agnostic of the source container,
makes it clearer that there is no ownership, is 8 bytes smaller,
and can be passed by value.
