| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
To use function style cast '(unsigned char)x' can't be replaced by
'unsigned char(x)'.
|
|
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
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
API added in rBa3ad5abf2fe85d623f9e78fefc34e27bdc14632e
|
|
|
|
- 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
|
|
This removes a lot of unnecessary code that is generated by
the compiler automatically.
In very few cases, a defaulted destructor in a .cc file is
still necessary, because of forward declarations in the header.
I removed some defaulted virtual destructors, because they are not
necessary, when the parent class has a virtual destructor already.
Defaulted constructors are only necessary when there is another
constructor, but the class should still be default constructible.
Differential Revision: https://developer.blender.org/D10911
|
|
When rendering with cycles at some point the manifest is trimmed. This
leads to incomplete/corrupted metadata. This patch will make sure that
the manifest parser doesn't crash.
This solved the issue when the manifest is trimmed at the start of a
hash. Eg '"Name":"'.
|
|
Seems like one of the example files on the cryptomatte github is
malformed and blender crashes when loading that file. This change will
try to load as much as possible from the manifest so it can still be
used.
This has also been reported to cryptomatte project.
|
|
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
|
|
|
|
But this time the root cause. Writing undo files is done in a separate
thread. This patch moved the updating of the matte_id when the user
actually changes the matte.
|
|
This reverts commit 7f3649874070de38131263317d02906d50279f93.
|
|
Warnings:
* readability-inconsistent-declaration-parameter-name
* readability-redundant-smartptr-get
|
|
Not sure this fixes the root cause. It seems that memory corruption
happens in dynstr. This patch replaces dynstr with a streamstring.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Missing code flow.
|
|
|
|
Current implementation was to restricting for future enhancements where
the CryptomatterLayer could be read from existing metadata.
|
|
|
|
|
|
BKE_cryptomatte_extract_layer_name was using std::isdigit
without including <cctype> somehow only MSVC 2017 had a
problem with that.
|
|
This change will try to add meta data when using a multilayered open
exr file output node in the compositor. It adds the current scene meta
data and converts existing cryptomatte keys so it follows the
naming that is configured in the file output node.
This change supports the basic use-case where the compositor is
used to output cryptomatte layers with a different naming scheme to
support external compositors. In this case the Multilayered OpenEXR
files are used and the meta data is read from the render result.
Meta data is found when render layer node is connected with the
file output node without any other nodes in between. Redirects and empty
node groups are allowed.
The patch has been verified to work with external compositors.
See https://devtalk.blender.org/t/making-sense-of-cryptomatte-usage-in-third-party-programs/16576/17
See patch for example files.
Reviewed By: Sergey Sharybin
Differential Revision: https://developer.blender.org/D10016
|
|
|
|
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
|
|
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.
|
