Commit Graph

15 Commits

Author SHA1 Message Date
1a81d268a1 Materials: support changing materials during evaluation
This commit allows that the evaluated geometry of an object has
different materials from the original geometry. This is needed
for geometry nodes.

The main thing that changes for render engines and exporters
is that the number of material slots on an object and its geometry
might not match anymore. For original data, the slot counts are
still equal, but not for evaluated data.

Accessing material slots though rna stays the same. The behavior
adapts automatically depending on whether the object is evaluated.

When accessing materials of an object through `BKE_object_material_*`
one has to use a new api for evaluated objects:
`BKE_object_material_get_eval` and `BKE_object_material_count_eval`.
In the future, the different behavior might be hidden behind a more
general C api, but that would require quite a few more changes.

The ground truth for the number of materials is the number of materials
on the geometry now. This is important in the current design, because
Eevee needs to know the number of materials just based on the mesh in
`mesh_render_mat_len_get` and similar places.

In a few places I had to add a special case for mesh edit mode to get it
to work properly. This is unfortunate, but I don't see a way around that
for now.

Differential Revision: https://developer.blender.org/D11236
2021-05-19 10:23:09 +02:00
bddc987ba3 Cleanup: clang format 2021-05-13 12:44:28 +10:00
6cd4bb9435 Fix T87764: Mem-leak during viewport rendering.
When a scene uses cryptomatte the viewport rendering would lead to a
memory leak. The reason was that all image renders (viewport+final)
activated cryptomatte. But is only used for final rendering.

This patch only activates cryptomatte when doing final rendering.
2021-05-10 13:33:34 +02:00
61b3870981 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 16:37:42 +01:00
79f34447d6 Cleanup: CryptomatteLayer structure.
Current implementation was to restricting for future enhancements where
the CryptomatterLayer could be read from existing metadata.
2021-02-24 15:18:31 +01:00
10e3b2dc8e Cryptomatte: Incorrect Coverage with Volumetrics
Related to {D10286}. When volumetrics are used in the scene the coverage
is incorrect. The reason is that the current sample is 1 over the num
samples that are calculated.
2021-02-03 15:27:52 +01:00
fc669a4c3e Cleanup: spelling 2021-01-27 15:28:24 +11:00
292685ea39 Fix T84878: Eevee cryptomatte broken with stereoscopy
During multiview rendering the `cryptomatte_accum_buffer` is not cleared
between the views and leaves artifacts on the next view to be rendered.
This change clears the accum buffer when it already exists and will be
reused for the next view.
2021-01-25 09:40:03 +01:00
bc58425862 Cleanup: clang-format, trailing space 2021-01-13 13:15:22 +11:00
Jeroen Bakker
1f41bdc6f3 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 15:03:05 +01:00
6714b800d1 Cryptomatte: apply volume transmittance to Eevee.
This patch will add volumetric transmittance to the cryptomatte coverage
data of all samples when post processing the cryptomatte passes.

It was discussed with Cycles that this is desired, but tricky to
implement in Cycles.
2020-12-14 15:03:29 +01:00
Evan Wilson
6e4fccd9fa Correct the order of the last two arguments in eevee_cryptomatte_shading_group_create
When compiling on Windows, the following warnings occur:
```[3468/4560] Building C object source\blender\draw\CMakeFiles\bf_draw.dir\engines\eevee\eevee_cryptomatte.c.obj
C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_cryptomatte.c(306): warning C4047: 'function': 'bool' differs in levels of indirection from 'void *'
C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_cryptomatte.c(306): warning C4024: 'eevee_cryptomatte_shading_group_create': different types for formal and actual parameter 5```

As @Severin pointed out [here](https://developer.blender.org/rB76a0b322e4d3244e59a154c8255b84a4fbc33117#288960), this is due to the last two arguments being flipped.  This diff corrects the order.

Reviewed By: Severin, fclem

Differential Revision: https://developer.blender.org/D9809
2020-12-11 08:45:05 +01:00
fff0032a25 Cleanup: spelling 2020-12-07 13:25:53 +11:00
5c3fa5a424 Cleanup: correct enum type 2020-12-07 13:25:49 +11:00
Jeroen Bakker
76a0b322e4 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:46:34 +01:00