2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2022-08-10 09:14:22 +02:00
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
Compositor: Avoid redundant output computations
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
2025-02-04 08:34:48 +01:00
|
|
|
#include <cstdint>
|
|
|
|
|
|
2025-07-25 15:40:45 +02:00
|
|
|
#include "BLI_bounds_types.hh"
|
2025-10-17 12:57:50 +02:00
|
|
|
#include "BLI_enum_flags.hh"
|
2023-01-04 00:14:55 +01:00
|
|
|
#include "BLI_math_vector_types.hh"
|
2022-08-10 09:14:22 +02:00
|
|
|
#include "BLI_string_ref.hh"
|
|
|
|
|
|
|
|
|
|
#include "DNA_scene_types.h"
|
|
|
|
|
|
2024-03-23 01:24:18 +01:00
|
|
|
#include "GPU_shader.hh"
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2023-12-22 13:12:17 +02:00
|
|
|
#include "COM_domain.hh"
|
2024-07-11 11:03:03 +02:00
|
|
|
#include "COM_meta_data.hh"
|
2024-05-28 08:13:46 +02:00
|
|
|
#include "COM_profiler.hh"
|
Compositor: Refactor File Output node
This patches refactors the compositor File Output mechanism and
implements the file output node for the Realtime Compositor. The
refactor was done for the following reasons:
1. The existing file output mechanism relied on a global EXR image
resource where the result of each compositor execution for each
view was accumulated and stored in the global resource, until the
last view is executed, when the EXR is finally saved. Aside from
relying on global resources, this can cause effective memory leaks
since the compositor can be interrupted before the EXR is written and
closed.
2. We need common code to share between all compositors since we now
have multiple compositor implementations.
3. We needed to take the opportunity to fix some of the issues with the
existing implementation, like lossy compression of data passes,
and inability to save single values passes.
The refactor first introduced a new structure called the Compositor
Render Context. This context stores compositor information related to
the render pipeline and is persistent across all compositor executions
of all views. Its extended lifetime relative to a single compositor
execution lends itself well to store data that is accumulated across
views. The context currently has a map of File Output objects. Those
objects wrap a Render Result structure and can be used to construct
multi-view images which can then be saved after all views are executed
using the existing BKE_image_render_write function.
Minor adjustments were made to the BKE and RE modules to allow saving
using the BKE_image_render_write function. Namely, the function now
allows the use of a source image format for saving as well as the
ability to not save the render result as a render by introducing two new
default arguments. Further, for multi-layer EXR saving, the existent of
a single unnamed render layer will omit the layer name from the EXR
channel full name, and only the pass, view, and channel ID will remain.
Finally, the Render Result to Image Buffer conversion now take he number
of channels into account, instead of always assuming color channels.
The patch implements the File Output node in the Realtime Compositor
using the aforementioned mechanisms, replaces the implementation of the
CPU compositor using the same Realtime Compositor implementation, and
setup the necessary logic in the render pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113982
2023-12-13 11:08:03 +01:00
|
|
|
#include "COM_render_context.hh"
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
#include "COM_result.hh"
|
2022-11-04 16:14:22 +02:00
|
|
|
#include "COM_static_cache_manager.hh"
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2024-12-17 11:39:04 +01:00
|
|
|
namespace blender::compositor {
|
2022-08-10 09:14:22 +02:00
|
|
|
|
Compositor: Avoid redundant output computations
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
2025-02-04 08:34:48 +01:00
|
|
|
/* Enumerates the possible outputs that the compositor can compute. */
|
|
|
|
|
enum class OutputTypes : uint8_t {
|
|
|
|
|
None = 0,
|
|
|
|
|
Composite = 1 << 0,
|
|
|
|
|
Viewer = 1 << 1,
|
|
|
|
|
FileOutput = 1 << 2,
|
|
|
|
|
Previews = 1 << 3,
|
|
|
|
|
};
|
2025-10-17 12:57:50 +02:00
|
|
|
ENUM_OPERATORS(OutputTypes)
|
Compositor: Avoid redundant output computations
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
2025-02-04 08:34:48 +01:00
|
|
|
|
2022-08-10 09:14:22 +02:00
|
|
|
/* ------------------------------------------------------------------------------------------------
|
|
|
|
|
* Context
|
|
|
|
|
*
|
|
|
|
|
* A Context is an abstract class that is implemented by the caller of the evaluator to provide the
|
|
|
|
|
* necessary data and functionalities for the correct operation of the evaluator. This includes
|
|
|
|
|
* providing input data like render passes and the active scene, as well as references to the data
|
2025-02-12 15:59:45 +01:00
|
|
|
* where the output of the evaluator will be written. Finally, the class have an instance of a
|
|
|
|
|
* static resource manager for acquiring cached resources efficiently. */
|
2022-08-10 09:14:22 +02:00
|
|
|
class Context {
|
|
|
|
|
private:
|
2022-11-04 16:14:22 +02:00
|
|
|
/* A static cache manager that can be used to acquire cached resources for the compositor
|
|
|
|
|
* efficiently. */
|
|
|
|
|
StaticCacheManager cache_manager_;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
|
|
|
|
public:
|
2023-06-21 05:41:49 +02:00
|
|
|
/* Get the compositing scene. */
|
|
|
|
|
virtual const Scene &get_scene() const = 0;
|
|
|
|
|
|
2023-06-05 17:18:38 +02:00
|
|
|
/* Get the node tree used for compositing. */
|
|
|
|
|
virtual const bNodeTree &get_node_tree() const = 0;
|
|
|
|
|
|
Compositor: Avoid redundant output computations
This patch allows the compositor context to specify exactly which
outputs it needs, selecting from: Composite, Viewer, File Output, and
Previews. Previously, the compositor fully executed if any of those were
needed, without granular control on which outputs are needed exactly.
For the viewport compositor engine, it requests Composite and Viewer,
with no Previews or File Outputs.
For the render pipeline, it requests Composite and File Output, with
node Viewer or Previews.
For the interactive compositor, it requests Viewer if the backdrop is
visible or an image editor with the viewer image is visible, it requests
Compositor if an image editor with the render result is visible, it
requests Previews if a node editor has previews overlay enabled. File
outputs are never requested.
Pull Request: https://projects.blender.org/blender/blender/pulls/133960
2025-02-04 08:34:48 +01:00
|
|
|
/* Returns all output types that should be computed. */
|
|
|
|
|
virtual OutputTypes needed_outputs() const = 0;
|
2024-07-26 19:01:11 +03:00
|
|
|
|
Realtime Compositor: Allow limited compositing region
This patch allows the realtime compositor to be limited to a specific
compositing region that is a subset of the full render region. In the
context of the viewport compositor, when the viewport is in camera view
and has a completely opaque passepartout, the compositing region will be
limited to the visible camera region.
On the user-level, this gives the user the ability to make the result of
the compositor invariant of the aspect ratio, shift, and zoom of the
viewport, making the result in the viewport identical to the final
render compositor assuming size relative operations.
It should be noted that compositing region is the *visible* camera
region, that is, the result of the intersection of the camera region and
the render region. So the user should be careful not to shift or zoom
the view such that the camera border extends outside of the viewport to
have the aforementioned benefits. While we could implement logic to fill
the areas outside of the render region with zeros in some cases, there
are many other ambiguous cases where such a solution wouldn't work,
including the problematic case where the user zooms in very close,
making the camera region much bigger than that of the render region.
Differential Revision: https://developer.blender.org/D16899
Reviewed By: Clement Foucault
2023-01-06 14:42:00 +02:00
|
|
|
/* Get the rectangular region representing the area of the input that the compositor will operate
|
|
|
|
|
* on. Conversely, the compositor will only update the region of the output that corresponds to
|
|
|
|
|
* the compositing region. In the base case, the compositing region covers the entirety of the
|
2025-07-25 07:50:52 +02:00
|
|
|
* render region. In other cases, the compositing region might be a subset of the render region.
|
|
|
|
|
* Callers should check the validity of the region through is_valid_compositing_region(), since
|
|
|
|
|
* the region can be zero sized. */
|
2025-07-25 15:40:45 +02:00
|
|
|
virtual Bounds<int2> get_compositing_region() const = 0;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2024-08-22 14:48:52 +03:00
|
|
|
/* Get the result where the result of the compositor should be written. */
|
VSE: Execute modifiers in strip-local space (#145688)
Currently when a strip has a transform that does not fill the whole
render area, first the image of the strip is transformed, and then
any modifiers are applied on that. This is mostly in the new
Compositor modifier, where procedural textures, gradients, image
coordinates "stick to the screen" instead of following the transformed
strip.
This changes the behavior so that first the modifiers are applied
to the strip image, and then the strip is transformed. This is
potentially a visually breaking change:
- This can alter visual look of existing strip, especially if they are
scaled. Previous behavior was first scale filtering, then modifier;
now it is first modifier, then scale filtering.
- Most obvious change is Compositor modifier (which is new in 5.0).
- Compositor modifier can actually expand the input image (e.g. Blur
node with "expand bounds" option set), and that works.
- Note that Masks continue to be applied in global/screen space. There
can be small look differences with rotated/scaled strips that use
masks, due to Mask application now needing to do filtered mask image
lookups.
- If anyone needs previous behavior (modifier is applied on the
"whole screen"), they can put transformed strip into a meta strip,
and apply the modifier on the meta strip itself.
Compositor modifier examples with images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146181
2025-10-07 13:51:41 +02:00
|
|
|
virtual Result get_output(Domain domain) = 0;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2024-08-16 16:38:47 +03:00
|
|
|
/* Get the result where the result of the compositor viewer should be written, given the domain
|
2024-10-04 14:25:16 +02:00
|
|
|
* of the result to be viewed, its precision, and whether the output is a non-color data image
|
|
|
|
|
* that should be displayed without view transform. */
|
2025-07-25 14:40:17 +02:00
|
|
|
virtual Result get_viewer_output(Domain domain, bool is_data, ResultPrecision precision) = 0;
|
2023-06-09 15:53:08 +02:00
|
|
|
|
2025-07-25 14:40:17 +02:00
|
|
|
/* Get the result where the given input is stored. */
|
2025-09-30 11:35:02 +02:00
|
|
|
virtual Result get_input(StringRef name) = 0;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2025-07-25 07:50:52 +02:00
|
|
|
/* True if the compositor should use GPU acceleration. */
|
|
|
|
|
virtual bool use_gpu() const = 0;
|
|
|
|
|
|
2025-09-30 11:35:02 +02:00
|
|
|
/* Get the result where the given pass is stored. */
|
|
|
|
|
virtual Result get_pass(const Scene *scene, int view_layer, const char *name);
|
|
|
|
|
|
2025-07-28 07:55:46 +02:00
|
|
|
/* Get the render settings for compositing. This could be different from scene->r render settings
|
|
|
|
|
* in case the render size or other settings needs to be overwritten. */
|
|
|
|
|
virtual const RenderData &get_render_data() const;
|
|
|
|
|
|
2025-07-25 07:50:52 +02:00
|
|
|
/* Get the name of the view currently being rendered. If the context is not multi-view, return an
|
|
|
|
|
* empty string. */
|
|
|
|
|
virtual StringRef get_view_name() const;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
/* Get the precision of the intermediate results of the compositor. */
|
2025-07-25 07:50:52 +02:00
|
|
|
virtual ResultPrecision get_precision() const;
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
|
2022-08-10 09:14:22 +02:00
|
|
|
/* Set an info message. This is called by the compositor evaluator to inform or warn the user
|
|
|
|
|
* about something, typically an error. The implementation should display the message in an
|
|
|
|
|
* appropriate place, which can be directly in the UI or just logged to the output stream. */
|
2025-07-25 07:50:52 +02:00
|
|
|
virtual void set_info_message(StringRef message) const;
|
2022-08-10 09:14:22 +02:00
|
|
|
|
2025-01-31 07:43:00 +01:00
|
|
|
/* True if the compositor should treat viewers as composite outputs because it has no concept of
|
|
|
|
|
* or support for viewers. */
|
Compositor: Replace Composite node with Group Output node
This patch replaces the Composite node with the Group Output node as the
primary compositor output. The old node was removed and versioned. This
was done for consistency with Geometry Nodes and in preparation for more
generic use of the compositor in VSE modifiers, layered compositing, NPR
multi-stage compositing, and more.
The Group Output node relies on the node tree interface, so we now have
a default interface of a single input and a single output. For now, only
the first input is considered while the rest are ignored, just like the
Geometry Nodes design. Furthermore, the input is required to be of type
color. Warnings and errors are issues if any of those are not met, also
similar to Geometry Nodes.
This introduces a new limitation: Composite outputs can no longer exist
in node groups, since they obviously then act as their respective group
outputs.
A refactor for the compositor scheduler is needed to simplify the logic
after this change, but this will be done in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/142232
2025-07-24 13:41:56 +02:00
|
|
|
virtual bool treat_viewer_as_compositor_output() const;
|
2025-01-31 07:43:00 +01:00
|
|
|
|
VSE: Execute modifiers in strip-local space (#145688)
Currently when a strip has a transform that does not fill the whole
render area, first the image of the strip is transformed, and then
any modifiers are applied on that. This is mostly in the new
Compositor modifier, where procedural textures, gradients, image
coordinates "stick to the screen" instead of following the transformed
strip.
This changes the behavior so that first the modifiers are applied
to the strip image, and then the strip is transformed. This is
potentially a visually breaking change:
- This can alter visual look of existing strip, especially if they are
scaled. Previous behavior was first scale filtering, then modifier;
now it is first modifier, then scale filtering.
- Most obvious change is Compositor modifier (which is new in 5.0).
- Compositor modifier can actually expand the input image (e.g. Blur
node with "expand bounds" option set), and that works.
- Note that Masks continue to be applied in global/screen space. There
can be small look differences with rotated/scaled strips that use
masks, due to Mask application now needing to do filtered mask image
lookups.
- If anyone needs previous behavior (modifier is applied on the
"whole screen"), they can put transformed strip into a meta strip,
and apply the modifier on the meta strip itself.
Compositor modifier examples with images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146181
2025-10-07 13:51:41 +02:00
|
|
|
/* True if the compositor input/output should use output region/bounds setup in the context. */
|
|
|
|
|
virtual bool use_context_bounds_for_input_output() const
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2024-07-11 11:03:03 +02:00
|
|
|
/* Populates the given meta data from the render stamp information of the given render pass. */
|
|
|
|
|
virtual void populate_meta_data_for_pass(const Scene *scene,
|
|
|
|
|
int view_layer_id,
|
|
|
|
|
const char *pass_name,
|
|
|
|
|
MetaData &meta_data) const;
|
|
|
|
|
|
Compositor: Refactor File Output node
This patches refactors the compositor File Output mechanism and
implements the file output node for the Realtime Compositor. The
refactor was done for the following reasons:
1. The existing file output mechanism relied on a global EXR image
resource where the result of each compositor execution for each
view was accumulated and stored in the global resource, until the
last view is executed, when the EXR is finally saved. Aside from
relying on global resources, this can cause effective memory leaks
since the compositor can be interrupted before the EXR is written and
closed.
2. We need common code to share between all compositors since we now
have multiple compositor implementations.
3. We needed to take the opportunity to fix some of the issues with the
existing implementation, like lossy compression of data passes,
and inability to save single values passes.
The refactor first introduced a new structure called the Compositor
Render Context. This context stores compositor information related to
the render pipeline and is persistent across all compositor executions
of all views. Its extended lifetime relative to a single compositor
execution lends itself well to store data that is accumulated across
views. The context currently has a map of File Output objects. Those
objects wrap a Render Result structure and can be used to construct
multi-view images which can then be saved after all views are executed
using the existing BKE_image_render_write function.
Minor adjustments were made to the BKE and RE modules to allow saving
using the BKE_image_render_write function. Namely, the function now
allows the use of a source image format for saving as well as the
ability to not save the render result as a render by introducing two new
default arguments. Further, for multi-layer EXR saving, the existent of
a single unnamed render layer will omit the layer name from the EXR
channel full name, and only the pass, view, and channel ID will remain.
Finally, the Render Result to Image Buffer conversion now take he number
of channels into account, instead of always assuming color channels.
The patch implements the File Output node in the Realtime Compositor
using the aforementioned mechanisms, replaces the implementation of the
CPU compositor using the same Realtime Compositor implementation, and
setup the necessary logic in the render pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113982
2023-12-13 11:08:03 +01:00
|
|
|
/* Get a pointer to the render context of this context. A render context stores information about
|
|
|
|
|
* the current render. It might be null if the compositor is not being evaluated as part of a
|
|
|
|
|
* render pipeline. */
|
|
|
|
|
virtual RenderContext *render_context() const;
|
|
|
|
|
|
2024-05-28 08:13:46 +02:00
|
|
|
/* Get a pointer to the profiler of this context. It might be null if the compositor context does
|
|
|
|
|
* not support profiling. */
|
|
|
|
|
virtual Profiler *profiler() const;
|
|
|
|
|
|
2024-04-16 09:10:36 +02:00
|
|
|
/* Gets called after the evaluation of each compositor operation. See overrides for possible
|
|
|
|
|
* uses. */
|
|
|
|
|
virtual void evaluate_operation_post() const;
|
|
|
|
|
|
2024-02-16 08:32:03 +01:00
|
|
|
/* Returns true if the compositor evaluation is canceled and that the evaluator should stop
|
|
|
|
|
* executing as soon as possible. */
|
|
|
|
|
virtual bool is_canceled() const;
|
|
|
|
|
|
2025-02-12 15:59:45 +01:00
|
|
|
/* Resets the context's internal structures like the cache manager. This should be called before
|
|
|
|
|
* every evaluation. */
|
2024-05-28 08:13:46 +02:00
|
|
|
void reset();
|
|
|
|
|
|
2024-02-06 12:57:49 +02:00
|
|
|
/* Get the size of the compositing region. See get_compositing_region(). The output size is
|
|
|
|
|
* sanitized such that it is at least 1 in both dimensions. However, the developer is expected to
|
|
|
|
|
* gracefully handled zero sizes regions by checking the is_valid_compositing_region method. */
|
Realtime Compositor: Allow limited compositing region
This patch allows the realtime compositor to be limited to a specific
compositing region that is a subset of the full render region. In the
context of the viewport compositor, when the viewport is in camera view
and has a completely opaque passepartout, the compositing region will be
limited to the visible camera region.
On the user-level, this gives the user the ability to make the result of
the compositor invariant of the aspect ratio, shift, and zoom of the
viewport, making the result in the viewport identical to the final
render compositor assuming size relative operations.
It should be noted that compositing region is the *visible* camera
region, that is, the result of the intersection of the camera region and
the render region. So the user should be careful not to shift or zoom
the view such that the camera border extends outside of the viewport to
have the aforementioned benefits. While we could implement logic to fill
the areas outside of the render region with zeros in some cases, there
are many other ambiguous cases where such a solution wouldn't work,
including the problematic case where the user zooms in very close,
making the camera region much bigger than that of the render region.
Differential Revision: https://developer.blender.org/D16899
Reviewed By: Clement Foucault
2023-01-06 14:42:00 +02:00
|
|
|
int2 get_compositing_region_size() const;
|
|
|
|
|
|
2024-02-06 12:57:49 +02:00
|
|
|
/* Returns true if the compositing region has a valid size, that is, has at least one pixel in
|
|
|
|
|
* both dimensions, returns false otherwise. */
|
|
|
|
|
bool is_valid_compositing_region() const;
|
|
|
|
|
|
2023-05-01 11:29:06 +02:00
|
|
|
/* Get the normalized render percentage of the active scene. */
|
|
|
|
|
float get_render_percentage() const;
|
|
|
|
|
|
2022-08-10 09:14:22 +02:00
|
|
|
/* Get the current frame number of the active scene. */
|
|
|
|
|
int get_frame_number() const;
|
|
|
|
|
|
|
|
|
|
/* Get the current time in seconds of the active scene. */
|
|
|
|
|
float get_time() const;
|
|
|
|
|
|
2025-07-25 07:50:52 +02:00
|
|
|
/* Get the OIDN denoiser quality which should be used if the user doesn't explicitly set
|
|
|
|
|
* denoising quality on a node. */
|
|
|
|
|
eCompositorDenoiseQaulity get_denoise_quality() const;
|
|
|
|
|
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
/* Get a GPU shader with the given info name and precision. */
|
2025-08-11 09:34:28 +02:00
|
|
|
gpu::Shader *get_shader(const char *info_name, ResultPrecision precision);
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
|
|
|
|
|
/* Get a GPU shader with the given info name and context's precision. */
|
2025-08-11 09:34:28 +02:00
|
|
|
gpu::Shader *get_shader(const char *info_name);
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
|
2024-08-05 18:38:32 +03:00
|
|
|
/* Create a result of the given type and precision. */
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
Result create_result(ResultType type, ResultPrecision precision);
|
|
|
|
|
|
2024-08-05 18:38:32 +03:00
|
|
|
/* Create a result of the given type using the context's precision. */
|
Realtime Compositor: Support full precision compositing
This patch adds support for full precision compositing for the Realtime
Compositor. A new precision option was added to the compositor to change
between half and full precision compositing, where the Auto option uses
half for the viewport compositor and the interactive render compositor,
while full is used for final renders.
The compositor context now need to implement the get_precision() method
to indicate its preferred precision. Intermediate results will be stored
using the context's precision, with a number of exceptions that can use
a different precision regardless of the context's precision. For
instance, summed area tables are always stored in full float results
even if the context specified half float. Conversely, jump flooding
tables are always stored in half integer results even if the context
specified full. The former requires full float while the latter has no
use for it.
Since shaders are created for a specific precision, we need two variants
of each compositor shader to account for the context's possible
precision. However, to avoid doubling the shader info count and reduce
boilerplate code and development time, an automated mechanism was
employed. A single shader info of whatever precision needs to be added,
then, at runtime, the shader info can be adjusted to change the
precision of the outputs. That shader variant is then cached in the
static cache manager for future processing-free shader retrieval.
Therefore, the shader manager was removed in favor of a cached shader
container in the static cache manager.
A number of utilities were added to make the creation of results as well as
the retrieval of shader with the target precision easier. Further, a
number of precision-specific shaders were removed in favor of more
generic ones that utilizes the aforementioned shader retrieval
mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113476
2023-11-08 08:32:00 +01:00
|
|
|
Result create_result(ResultType type);
|
|
|
|
|
|
2022-11-04 16:14:22 +02:00
|
|
|
/* Get a reference to the static cache manager of this context. */
|
|
|
|
|
StaticCacheManager &cache_manager();
|
2022-08-10 09:14:22 +02:00
|
|
|
};
|
|
|
|
|
|
2024-12-17 11:39:04 +01:00
|
|
|
} // namespace blender::compositor
|