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
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
This patch moves the EEVEE depth of field shaders to eevee_shaders.c and
adds them to the eevee shaders test suite.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8771
This follows the GPU module naming of other buffers.
We pass name to distinguish each GPUUniformBuf in debug mode.
Also remove DRW_uniform_buffer interface.
This is in order to disolve GPU_draw.h into more meaningful code blocks.
All the Image related function are in `image_gpu.c`.
All the MovieClip related function are in `movieclip.c`.
The IMB module now has a connection with GPU. This is not strickly
necessary and the code could be move to `image_gpu.c` if needed.
The Image garbage collection is also ported to `image_gpu.c`.
When bl_use_gpu_context is set, an OpenGL context will be available for
OpenGL based render engines.
Differential Revision: https://developer.blender.org/D8305
This was caused by the step motion blur implementation.
`DRW_cache_restart` was reseting the cache and cause
`EEVEE_renderpasses_postprocess` to not work inside
`EEVEE_render_read_result`.
This revisit the render pipeline to support time slicing for better motion
blur.
We support accumulation with or without the Post-process motion blur.
If using the post-process, we reuse last step next motion data to avoid
another scene reevaluation.
This also adds support for hair motion blur which is handled in a similar
way as mesh motion blur.
The total number of samples is distributed evenly accross all timesteps to
avoid sampling weighting issues. For this reason, the sample count is
(internally) rounded up to the next multiple of the step count.
Only FX Motion BLur: {F8632258}
FX Motion Blur + 4 time steps: {F8632260}
FX Motion Blur + 32 time steps: {F8632261}
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D8079
This adds object motion blur vectors for EEVEE as well as better noise
reduction for it.
For TAA reprojection we just compute the motion vector on the fly based on
camera motion and depth buffer. This makes possible to store another motion
vector only for the blurring which is not useful for TAA history fetching.
Motion Data is saved per object & per geometry if using deformation blur.
We support deformation motion blur by saving previous VBO and modifying the
actual GPUBatch for the geometry to include theses VBOs.
We store Previous and Next frame motion in the same motion vector buffer
(RG for prev and BA for next). This makes non linear motion blur (like
rotating objects) less prone to outward/inward blur.
We also improve the motion blur post process to expand outside the objects
border. We use a tile base approach and the max size of the blur is set via
a new render setting.
We use a background reconstruction method that needs another setting
(Background Separation).
Sampling is done using a fixed 8 dithered samples per direction. The final
render samples will clear the noise like other stochastic effects.
One caveat is that hair particles are not yet supported. Support will
come in another patch.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7297
These are the modifications:
-With DRW modification we reduce the number of passes we need to populate.
-Rename passes for consistent naming.
-Reduce complexity in code compilation
-Cleanup how renderpass accumulation passes are setup, using pass instances.
-Make sculpt mode compatible with shadows
-Make hair passes compatible with SSS
-Error shader and lookdev materials now use standalone materials.
-Support default shader (world and material) using a default nodetree internally.
-Change BLEND_CLIP to be emulated by gpu nodetree. Making less shader variations.
-Use BLI_memblock for cache memory allocation.
-Renderpasses are handled by switching a UBO ref bind.
One major hack in this patch is the use of modified pointer as ghash keys.
This rely on the assumption that the keys will never overlap because the
number of options per key will never be bigger than the pointed struct.
The use of one single nodetree to support default material is also a bit hacky
since it won't support concurent usage of this nodetree.
(see EEVEE_shader_default_surface_nodetree)
Another change is that objects with shader errors now appear solid magenta instead
of shaded magenta. This is only because of code reuse purpose but could be changed
if really needed.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7642
Only the volume drawing part is really finished and exposed to the user. Hair
plugs into the existing hair rendering code and is fairly straightforward. The
pointcloud drawing is a hack using overlays rather than Eevee and workbench.
The most tricky part for volume rendering is the case where each volume grid
has a different transform, which requires an additional matrix in the shader
and non-trivial logic in Eevee volume drawing. In the common case were all the
transforms match we don't use the additional per-grid matrix in the shader.
Ref T73201, T68981
Differential Revision: https://developer.blender.org/D6955
SSS buffers are lazy initialized when needed. When shaders recompile the
SSS buffers could be incorrectly drawn. During the render passes project
we tried to fix this, but that resulted in incorrect result of the first
sample after a shader was compiled.
We revert this change knowing that we know the issue, but haven't found
a proper solution for it.
This patch adds new render passes to EEVEE. These passes include:
* Emission
* Diffuse Light
* Diffuse Color
* Glossy Light
* Glossy Color
* Environment
* Volume Scattering
* Volume Transmission
* Bloom
* Shadow
With these passes it will be possible to use EEVEE effectively for
compositing. During development we kept a close eye on how to get similar
results compared to cycles render passes there are some differences that
are related to how EEVEE works. For EEVEE we combined the passes to
`Diffuse` and `Specular`. There are no transmittance or sss passes anymore.
Cycles will be changed accordingly.
Cycles volume transmittance is added to multiple surface col passes. For
EEVEE we left the volume transmittance as a separate pass.
Known Limitations
* All materials that use alpha blending will not be rendered in the render
passes. Other transparency modes are supported.
* More GPU memory is required to store the render passes. When rendering
a HD image with all render passes enabled at max extra 570MB GPU memory is
required.
Implementation Details
An overview of render passes have been described in
https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses
Future Developments
* In this implementation the materials are re-rendered for Diffuse/Glossy
and Emission passes. We could use multi target rendering to improve the
render speed.
* Other passes can be added later
* Don't render material based passes when only requesting AO or Shadow.
* Add more passes to the system. These could include Cryptomatte, AOV's, Vector,
ObjectID, MaterialID, UV.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D6331
EEVEE Soft shadows were not rendered correctly during viewport
rendering. The reason for this is that during viewport rendering the
shadow buffers were only update once and not per sample. This resulted
that all the samples calculated the same shadow.
This fix moves the call to `EEVEE_shadows_update` from cache finished to
draw scene. This needs to happen before `EEVEE_lightprobes_refresh`.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6538
This patch will allow the user to select the EEVEE renderpass to be
shown in the viewport by default the combined pass will be shown.
Limitations:
* Viewport rendering stores the result in a `RenderResult`. RenderResult
is not aware of the type of data it holds. In many places where RenderResult
is used it is assumed that it stores a combined pass and the display+view
transform are applied.
I will propose to fix this in a future patch. But that is still being
designed and discussed.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6319
Most of the renderpasses in EEVEE used post-processing on the CPU. For
final image rendering this is sufficient, but when we want to display
the data to the user we don't want to transfer to the CPU to do post
processing to then upload it back to the GPU to display the result.
This patch moves the renderpass postprocessing to a GLSL shader.
This is the first step to do, before we will enable the renderpasses in the viewport.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6206
Alpha blended Transparency is now using dual source blending making it
fully compatible with cycles Transparent BSDF.
Multiply and additive blend mode can be achieved using some nodes and are
going to be removed.
We check if the previous iteration (sample) was using a valid double buffer.
If it wasn't, we request another iteration.
This fix the issue for viewport,viewport render and image render.
Related to T65761 Eevee render inconsistency between 3D View, Viewport render, and F12 Render
This is enabled with bl_use_eevee_viewport = True. It allows external engines
to generate an Cycles/Eevee shader node setup to emulate their materials in
the realtime viewport, or to leave it to users to do manually.
Removed bl_use_exclude_layers and bl_use_shading_nodes that did nothing
anymore. This should not break API compatibility, any scripts setting those
should continue to work the same as before.
Also adds descriptions for some RenderEngine settings.
This is too generic flag, and it might be used by anything, starting from
changes in transform ending with changes in ID properties.
The check here is to be as specific as possible. If that is not possible
the decision must be documented.
Related on T63111.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4923
This is to simplify the usage of Volumetrics.
Now it automatically detect if there is any Volumetric material in the
view and allocate the needed buffer if any.
EEVEE assumed that the OGL renderer did FSAA, as the FSAA was removed we
needed to revalidate this assumption. The temporal sampling only inited
the matrices during init phase. As now we need to update the matrices
for every sample rendered the code for updating the matrices was
isolated in a new function `EEVEE_temporal_sampling_update_matrices`.
Reviewed By: fclem
Maniphest Tasks: T64646
Differential Revision: https://developer.blender.org/D4871
- Add `render_aa` and `viewport_aa` sampling setting for workbench. 0
samples means no AA, 1 sample uses FXAA and more samples will use
TAA.
The viewport `gpu_viewport_quality` can still limit viewport anti-aliasing
method.
- Use TAA when rendering images. (this used to be CPU based FSAA)
- Removed `R_OSA` related settings.
Reviewers: fclem, brecht
Maniphest Tasks: T60847
Differential Revision: https://developer.blender.org/D4773
