tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/blenkernel/BKE_cryptomatte.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

64 lines
2.3 KiB
C
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-15 16:20:26 +02:00
/* SPDX-FileCopyrightText: 2020 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
/** \file
* \ingroup bke
*/
#pragma once
#include "BLI_sys_types.h"
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
#include "DNA_layer_types.h"
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
#ifdef __cplusplus
extern "C" {
#endif
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
/* Forward declarations. */
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
struct CryptomatteSession;
Cleanup: sort structs, file-lists
2021-02-18 04:14:17 +01:00
struct Material;
Cleanup: sort struct blocks
2020-12-16 06:26:23 +01:00
struct Object;
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
struct RenderResult;
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
struct Scene;
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
struct CryptomatteSession *BKE_cryptomatte_init(void);
Cryptomatte: Session from Existing Render Result. Utility to construct a cryptomatte session from a render result or openexr file. This will allow D3959 to be more aware of the context it is working on and would also support external render engines in the cryptomatte color picker.
2021-03-02 10:14:10 +01:00
struct CryptomatteSession *BKE_cryptomatte_init_from_render_result(
const struct RenderResult *render_result);
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
struct CryptomatteSession *BKE_cryptomatte_init_from_scene(const struct Scene *scene);
EEVEE-Next: Cryptomatte render passes. This change adds cryptomatte render passes to EEVEE-Next. Due to the upcoming viewport compositor we also improved cryptomatte so it will be real-time. This also allows viewing the cryptomatte passes in the viewport directly. {F13482749} A surface shader would store any active cryptomatte layer to a texture. Object hash is stored as R, Asset hash as G and Material hash as B. Hashes are only calculated when the cryptomatte layer is active to reduce any unneeded work. During film accumulation the hashes are separated and stored in a texture array that matches the cryptomatte standard. For the real-time use case sorting is skipped. For final rendering the samples are sorted and normalized. NOTE: Eventually we should also do sample normalization in the viewport in order to extract the correct mask when using the viewport compositor. Reviewed By: fclem Maniphest Tasks: T99390 Differential Revision: https://developer.blender.org/D15753
2022-09-13 11:07:30 +02:00
struct CryptomatteSession *BKE_cryptomatte_init_from_view_layer(
const struct ViewLayer *view_layer);
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
void BKE_cryptomatte_free(struct CryptomatteSession *session);
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
void BKE_cryptomatte_add_layer(struct CryptomatteSession *session, const char *layer_name);
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
Cryptomatte: Data structure in compositor node This changes the way how the mattes are stored in the compositor node. This used to be a single string what was decoded/encoded when needed. The new data structure stores all entries in `CryptomatteEntry` and is converted to the old `matte_id` property on the fly. This is done for some future changes in the workflow where a more structured approach leads to less confusing and easier to read code.
2020-12-14 16:14:21 +01:00
uint32_t BKE_cryptomatte_hash(const char *name, int name_len);
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
uint32_t BKE_cryptomatte_object_hash(struct CryptomatteSession *session,
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
const char *layer_name,
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
const struct Object *object);
uint32_t BKE_cryptomatte_material_hash(struct CryptomatteSession *session,
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
const char *layer_name,
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
const struct Material *material);
uint32_t BKE_cryptomatte_asset_hash(struct CryptomatteSession *session,
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
const char *layer_name,
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
const struct Object *object);
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
float BKE_cryptomatte_hash_to_float(uint32_t cryptomatte_hash);
Cleanup: move public doc-strings into headers for 'blenkernel' - Added space below non doc-string comments to make it clear these aren't comments for the symbols directly below them. - Use doxy sections for some headers. - Minor improvements to doc-strings. Ref T92709
2021-12-07 07:19:15 +01:00
/**
* Find an ID in the given main that matches the given encoded float.
*/
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
bool BKE_cryptomatte_find_name(const struct CryptomatteSession *session,
Cleanup: remove redundant const qualifiers for POD types MSVC used to warn about const mismatch for arguments passed by value. Remove these as newer versions of MSVC no longer show this warning.
2022-01-07 01:38:08 +01:00
float encoded_hash,
Compositor: Redesign Cryptomatte node for better usability In the current implementation, cryptomatte passes are connected to the node and elements are picked by using the eyedropper tool on a special pick channel. This design has two disadvantages - both connecting all passes individually and always having to switch to the picker channel are tedious. With the new design, the user selects the RenderLayer or Image from which the Cryptomatte layers are directly loaded (the type of pass is determined by an enum). This allows the node to automatically detect all relevant passes. Then, when using the eyedropper tool, the operator looks up the selected coordinates from the picked Image, Node backdrop or Clip and reads the picked object directly from the Renderlayer/Image, therefore allowing to pick in any context (e.g. by clicking on the Combined pass in the Image Viewer). The sampled color is looked up in the metadata and the actual name is stored in the cryptomatte node. This also allows to remove a hash by just removing the name from the matte id. Technically there is some loss of flexibility because the Cryptomatte pass inputs can no longer be connected to other nodes, but since any compositing done on them is likely to break the Cryptomatte system anyways, this isn't really a concern in practise. In the future, this would also allow to automatically translate values to names by looking up the value in the associated metadata of the input, or to get a better visualization of overlapping areas in the Pick output since we could blend colors now that the output doesn't have to contain the exact value. Idea + Original patch: Lucas Stockner Reviewed By: Brecht van Lommel Differential Revision: https://developer.blender.org/D3959
2021-03-16 07:37:30 +01:00
char *r_name,
Cleanup: reserve the term 'len' for string length
2023-05-13 09:34:23 +02:00
int name_maxncpy);
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
Cryptomatte: Data structure in compositor node This changes the way how the mattes are stored in the compositor node. This used to be a single string what was decoded/encoded when needed. The new data structure stores all entries in `CryptomatteEntry` and is converted to the old `matte_id` property on the fly. This is done for some future changes in the workflow where a more structured approach leads to less confusing and easier to read code.
2020-12-14 16:14:21 +01:00
char *BKE_cryptomatte_entries_to_matte_id(struct NodeCryptomatte *node_storage);
Cryptomatte: Manifest Parsing. This patch adds manifest parsing to Cryptomatte. Normally when loading cryptomatte layer from an OpenEXR file the manifest contains data to convert a hash to its original name of the object/material. In the future we want to use this to support lookup of cryptomatte hashes and show it to the user. Currently this logic isn't available to users (for now), but is required by D3959 where a new cryptomatte workflow is implemented.
2021-02-26 14:13:15 +01:00
void BKE_cryptomatte_matte_id_to_entries(struct NodeCryptomatte *node_storage,
Cryptomatte: Data structure in compositor node This changes the way how the mattes are stored in the compositor node. This used to be a single string what was decoded/encoded when needed. The new data structure stores all entries in `CryptomatteEntry` and is converted to the old `matte_id` property on the fly. This is done for some future changes in the workflow where a more structured approach leads to less confusing and easier to read code.
2020-12-14 16:14:21 +01:00
const char *matte_id);
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
void BKE_cryptomatte_store_metadata(const struct CryptomatteSession *session,
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
struct RenderResult *render_result,
Cryptomatte: Flexible Definition of CryptomatteLayers. Cryptomatte layers in Blender are predefined. Other render engines might have other naming schemes. This patch will allow creation of cryptomatte layers with other names. This will be used by D3959 to load cryptomatte openexr files from other render engines. EEVEE and Cycles still use our fix naming scheme so no changes are detectable by users.
2021-03-01 15:14:55 +01:00
const ViewLayer *view_layer);
Eevee Cryptomatte: Store hashes in render result meta data Stores cryptomatte hashes as meta data to the render result. Compositors could use this for lookup on names in stead of hashes. Differential Revision: https://developer.blender.org/D9553
2021-01-05 14:59:45 +01:00
EEVEE Cryptomatte Cryptomatte is a standard to efficiently create mattes for compositing. The renderer outputs the required render passes, which can then be used in the compositor to create masks for specified objects. Unlike the Material and Object Index passes, the objects to isolate are selected in compositing, and mattes will be anti-aliased. Cryptomatte was already available in Cycles this patch adds it to the EEVEE render engine. Original specification can be found at https://raw.githubusercontent.com/Psyop/Cryptomatte/master/specification/IDmattes_poster.pdf **Accurate mode** Following Cycles, there are two accuracy modes. The difference between the two modes is the number of render samples they take into account to create the render passes. When accurate mode is off the number of levels is used. When accuracy mode is active, the number of render samples is used. **Deviation from standard** Cryptomatte specification is based on a path trace approach where samples and coverage are calculated at the same time. In EEVEE a sample is an exact match on top of a prepared depth buffer. Coverage is at that moment always 1. By sampling multiple times the number of surface hits decides the actual surface coverage for a matte per pixel. **Implementation Overview** When drawing to the cryptomatte GPU buffer the depth of the fragment is matched to the active depth buffer. The hashes of each cryptomatte layer is written in the GPU buffer. The exact layout depends on the active cryptomatte layers. The GPU buffer is downloaded and integrated into an accumulation buffer (stored in CPU RAM). The accumulation buffer stores the hashes + weights for a number of levels, layers per pixel. When a hash already exists the weight will be increased. When the hash doesn't exists it will be added to the buffer. After all the samples have been calculated the accumulation buffer is processed. During this phase the total pixel weights of each layer is mapped to be in a range between 0 and 1. The hashes are also sorted (highest weight first). Blender Kernel now has a `BKE_cryptomatte` header that access to common functions for cryptomatte. This will in the future be used by the API. * Alpha blended materials aren't supported. Alpha blended materials support in render passes needs research how to implement it in a maintainable way for any render pass. This is a list of tasks that needs to be done for the same release that this patch lands on (Blender 2.92) * T82571 Add render tests. * T82572 Documentation. * T82573 Store hashes + Object names in the render result header. * T82574 Use threading to increase performance in accumulation and post processing. * T82575 Merge the cycles and EEVEE settings as they are identical. * T82576 Add RNA to extract the cryptomatte hashes to use in python scripts. Reviewed By: Clément Foucault Maniphest Tasks: T81058 Differential Revision: https://developer.blender.org/D9165
2020-12-04 08:28:43 +01:00
#ifdef __cplusplus
}
Cleanup: clang-format, trailing space Minor manual tweak to prevent wrapping an array into columns.
2021-03-22 04:22:37 +01:00
#endif