In Render properties > Color Management > Display.
* Off: Directly output image as produced by OpenColorIO. This is not correct
in general, but may be used when the system configuration and actual display
device is known to match the chosen display.
* Automatic: Display images consistent with most other applications, to preview
images and video for export. A best effort is made to emulate the chosen
display on the actual display device.
The option is grayed out when the current OpenColorIO config and display/view
does not support emulation.
Ref #145022, #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/146808
* Store scene linear to XYZ conversion matrix in each blend file, along
with the colorspace name. The matrix is the source of truth. The name
is currently only used for error logging about unknown color spaces.
* Add Working Space option in color management panel, to change the
working space for the entire blend file. Changing this will pop up
a dialog, with a default enabled option to convert all colors in
the blend file to the new working space. Note this is necessarily only
an approximation.
* Link and append automatically converts to the color space of the main
open blend file.
* There is builtin support for Rec.709, Rec.2020 and ACEScg working spaces,
in addition to the working space of custom OpenColorIO configs.
* Undo of working space for linked datablocks isn't quite correct when going
to a smaller gamut working space. This can be fixed by reloading the file
so the linked datablocks are reloaded.
Compatibility with blend files saved with a custom OpenColorIO config
is tricky, as we can not detect this.
* We assume that if the blend file has no information about the scene
linear color space, it is the default one from the active OCIO config.
And the same for any blend files linked or appended. This is effectively
the same behavior as before.
* Now that there is a warning when color spaces are missing, it is more
likely that a user will notice something is wrong and only save the
blend file with the correct config active.
* As no automatic working space conversion happens on file load, there is
an opportunity to correct things by changing the working space with
"Convert Colors" disabled. This can also be scripted for all blend files
in a project.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/145476
* Improve accuracy of warning when HDR display is not supported, taking into
account HDR mode on/off on Windows.
* When HDR mode is disabled on Windows, don't create a HDR swapchain. This
saves memory, and avoids a color difference on NVIDIA. That's because NVIDIA
is the only GPU we've tested that allows a HDR swapchain when HDR mode is
off, and we don't currently know the expected transforms for that case.
* Recreate swapchain when HDR mode on/off switch is detected.
* Update HDR info when window gains focus.
Note this means there is no wide gamut when Windows HDR is off, but it was
already not working. For that we may need to add support for something like
10bit VK_COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT, or whatever is commonly
available outside of HDR mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/144959
Implementation of the design task #142969.
This adds the following:
- Exact GPU interpolation of curves of all types.
- Radius attribute support.
- Cyclic curve support.
- Resolution attribute support.
- New Cylinder hair shape type.
What changed:
- EEVEE doesn't compute random normals for strand hairs anymore. These are considered legacy now.
- EEVEE now have an internal shadow bias to avoid self shadowing on hair.
- Workbench Curves Strip display option is no longer flat and has better shading.
- Legacy Hair particle system evaluates radius at control points before applying additional subdivision. This now matches Cycles.
- Color Attribute Node without a name do not fetch the active color attribute anymore. This now matches Cycles.
Notes:
- This is not 100% matching the CPU implementation for interpolation (see the epsilons in the tests).
- Legacy Hair Particle points is now stored in local space after interpolation.
The new cylinder shape allows for more correct hair shading in workbench and better intersection in EEVEE.
| | Strand | Strip | Cylinder |
| ---- | --- | --- | --- |
| Main |  |  | N/A |
| PR |  |  |  |
| | Strand | Strip | Cylinder |
| ---- | --- | --- | --- |
| Main |  | | N/A |
| PR | ||  |
Cyclic Curve, Mixed curve type, and proper radius support:
Test file for attribute lookup: [test_attribute_lookup.blend](/attachments/1d54dd06-379b-4480-a1c5-96adc1953f77)
Follow Up Tasks:
- Correct full tube segments orientation based on tangent and normal attributes
- Correct V resolution property per object
- More attribute type support (currently only color)
TODO:
- [x] Attribute Loading Changes
- [x] Generic Attributes
- [x] Length Attribute
- [x] Intercept Attribute
- [x] Original Coordinate Attribute
- [x] Cyclic Curves
- [x] Legacy Hair Particle conversion
- [x] Attribute Loading
- [x] Additional Subdivision
- [x] Move some function to generic headers (VertBuf, OffsetIndices)
- [x] Fix default UV/Color attribute assignment
Pull Request: https://projects.blender.org/blender/blender/pulls/143180
This was a temporary solution until we had proper HDR displays.
* Auto detect from the display + view transform if they are HDR, and
enable it automatically. This is based on encoding hdr-video in the config.
* If a HDR transform is selected and there is no HDR display support, an
info message will be shown in the color management panel.
* It is now possible to view HDR images in the image editor, without
needing to use "View as Render".
* There is no versioning to switch to a HDR display, because that also
affects image saving. So users will have to manually select the
"Rec.2100 PQ" display to see HDR colors again.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
This changes the engine identifier back to `BLENDER_EEVEE`.
We keep the `BLENDER_EEVEE_NEXT` identifier around for
versioning reasons (have to detect when it is the active
engine of a older file).
This also rename a bunch of pannels that were using `next`
in their name.
This is a breaking change for Addons compatibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/140282
This adds motion blur support for Grease Pencil.
We follow the same principle form EEVEE and use the existing
`antialiasing_accumulate` (SSAA) function to accumulate the
frames in range of the motion blur over time.
There is a new `motion_blur_steps` setting in the Grease
Pencil render settings to control the accuracy of the motion
blur. This will increase the render time.
Limitations:
* When Grease Pencil is composited into the scene, we only do
it for one the current frame and don't take the motion blur into
account. This will lead to hard edges currently.
* There is no viewport motion blur. This would need an entirely
new technique that can be computed in real-time.
Pull Request: https://projects.blender.org/blender/blender/pulls/139840
Improve labels and UI consistency.
- Update color labels: Object, Wireframe, Background
- Rename 'Single' shading color to 'Custom'. Move to the end.
- Rename 'Viewport' color to 'Custom' for consistency.
- Fix alignment of Object Color item labels
Pull Request: https://projects.blender.org/blender/blender/pulls/137408
This patch supports GPU OIDN denoising in the compositor. A new
compositor performance option was added to allow choosing between CPU,
GPU, and Auto device selection. Auto will use whatever the compositor is
using for execution.
The code is two folds, first, denoising code was adapted to use buffers
as opposed to passing in pointers to filters directly, this is needed to
support GPU devices. Second, device creation is now a bit more involved,
it tries to choose the device is being used by the compositor for
execution.
Matching GPU devices is done by choosing the OIDN device that matches
the UUID or LUID of the active GPU platform. We need both UUID and LUID
because not all platforms support both. UUID is supported on all
platforms except MacOS Metal, while LUID is only supported on Window and
MacOS metal.
If there is no active GPU device or matching is unsuccessful, we let
OIDN choose the best device, which is typically the fastest.
To support this case, UUID and LUID identifiers were added to the
GPUPlatformGlobal and are initialized by the GPU backend if supported.
OpenGL now requires GL_EXT_memory_object and GL_EXT_memory_object_win32
to support this use case, but it should function without it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136660
This adds a new more accurate antialiasing to the Grease Pencil
render engine. This is only available for render.
This Accumulation AA doesn't replace the SMAA. SMAA is still
used by the viewport and for removing aliasing from the
depth buffer. However, using both at the same time can lead
to overblurred result.
Here are some measurements for how much the render time
increases compared to the baseline with different (SSAA) sample
counts (using an example production file, rendered at 1080p,
results might vary depending on the scene complexity):
* 8 samples: +0.14 s
* 16 samples +0.36 s
* 32 samples: +0.58 s
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/136551
- Wrap the closing parenthesis onto it's own line
which makes assignments to the return value
read better.
- Reduce right-shift with multi-line function calls.
This commit exposes the "Quality" option of the Open Image Denoiser
to the user for the denoise node in the compositor.
There are a few quality modes:
- High - Highest quality, but takes the longest to process.
- Balanced - Slightly lower quality, but usually halves
the processing time compared to High.
- Fast - Further reduce the quality, for a small increase in
speed over Balanced.
Along with that there is a `Follow Scene` option which will use the
quality set in the scene settings.
This allows users that have multiple denoise nodes
(E.g. For multi-pass denoising), to quickly switch all nodes between
different quality modes.
Performance (denoising time):
High: 13 seconds
Balanced: 6 seconds
Fast: 5 seconds
Test setup:
CPU: AMD Ryzen 9 5950X
Denoising a 3840x2160 render
---
Follow ups:
Ideally the "Denoise Nodes" UI panel in the render properties panel
would be hidden if the compositor setup does not contain any
denoise nodes.
However implementing this efficiently can be difficult and so it was
decided this task was outside the scope of this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/130252
Add a toggle for Fast GI Approximation in the header of the panel,
following Cycles layout.
Move the `Max Roughness` setting inside the panel, and rename to
Threshold.
Since Fast GI Approximation only has any effect when Threshold/
Max Roughness is below the max (1.0), gray out the rest of the
panel when at that value.
Co-authored-by: Clément FOUCAULT <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/125452
This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.
The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).
The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.
As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.
Presets are supported, and all the CIE standard illuminants are included.
One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...
Adding support for this to the compositor should be quite easy and is planned
as a next step.
Pull Request: https://projects.blender.org/blender/blender/pulls/123278
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
While easier to understand, the conventionnal global
scene thickness parameter have some downside:
- It doesn't scale with larger scenes since the
distant samples have small thickness
- It doesn't handle fine geometric variation in
foreground.
The proposed angular thicknes makes all sample
have the same angular span. This makes it
distance independant and capture different occluder
thickness with less artifacts. The downside is
that the occluders have the same angular span
at any distance which makes the same occluder inflate
with distance.
A downside is that the geometry near the shading point is
under-represented. Leaving light leaking or lack of AO
at contact points. To fix this, we introduce back a
geometric thickness parameter.
Pull Request: https://projects.blender.org/blender/blender/pulls/122334
This new `Method` property allows to replace Diffuse GI
by simple ambient occlusion. This can be desirable for
performance or look.
This doesn't add the memory savings but there are already
some performance gain by using this option.
This allow to reduce the amount of noise and reduce
the lost energy caused by low thickness and large
stride (low sample count).
Actual number of rays is twice the UI count.
The reasonning is that we already have a resolution limit
slider per light.
The global shadow resolution scale is usefull as a quick
speedup option to reduce shadow cost for viewport regular
work or for quick rendering. For final render, the per
light resolution limit is more suited than a LOD scale
since it doesn't modify the filtering of based on distance
from the camera.
This feature is really not hard to add back if there is
a compelling use case for it.
Jittered Soft Shadows support.
Improves soft shadow quality at the cost of re-rendering shadow maps every sample.
Disabled by default in the viewport unless enabled in the Scene settings.
| Tracing-only | Jitter-only | Jitter+Over-blur |
| --- | --- | --- |
|  |  |  |
Tracing-only is the method used by default in EEVEE-Next.
Jitter-only is the method used by EEVEE-Legacy Soft Shadows.
Jitter+Over-blur combines both.
Co-authored by Miguel Pozo @pragma37 (initial patch #119753)
Pull Request: https://projects.blender.org/blender/blender/pulls/121836
Sun extraction convert part of light comming from the world to a
sun light which increases the quality of the rendering. The goal
of this feature is to workaround the limitation of the storage
techniques used for environment lighting inside EEVEE.
This first implementation works by clamping the world lighting and
summing the excess lighting and (and its incomming directions) to
deduce the sun position.
All the lighting is then transfered into this light power. The sun
angle is computed based on the directionnality of the excess lighting,
the more divergent the excess lighting is, the bigger the angle.
This has a few benefits:
- It's stable and behave well under animation. This is because we
average a lot of data.
- It's fast as it can be done inside the remap shader in one pass.
- It requires only one parameter, the clamp threshold.
However, it has some issue:
- It modifies the lighting as we change the incomming direction for
excess lighting away from the chosen sun direction. This could be fixed
by masking only lighting around the chosen sun direction (requires 2
passes, slower).
- Given that this only average the direction, it behaves poorly if there
two opposite bright light sources (it puts the sun in the middle). This
could be fixed by extracting more suns, but that becomes more complex
and requires even more passes.
- It looks bad if the summed lighting is not supposed to be a perfect
disk in specular reflections or if the sources are too divergent as the
disk is too big and the approximation fails short. This could be
mitigated by adding an upper bound to the sun radius. For now we
workaround this issue by exposing the sun angle parameter in the UI.
A more precise algorithm can be implemented in the future to avoid
having to deal with these limitations. A possibility is to use
importance sampling to randomize sun position. But that would be only
for final render.
Pull Request: https://projects.blender.org/blender/blender/pulls/121455
Effectively, make GPU compositor available without need to enable
an experimental feature set.
The compositor device is now exposed in the Performance panel of
Render Buttons. It is also still available in the compositor's
N-panel, together with some other options which are more about how
editing works, and not exactly related to render performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/121398
This avoids negative color darkening caused by strong
directionnal lighting.
However, this reduce the contrast a lot since the
deringing is done on the unclampped spherical harmonics
which is itself extracted from unclamped values from
the world.
The solution to this is to add the parameter for
clamping the world light. This setting will be
reused for #68478.
Fix#116036
Pull Request: https://projects.blender.org/blender/blender/pulls/121303
The goal of this PR is to remove any user facing parameter
bias that fixes issues that are caused by inherent nature of
the shadow map (aliasing or discretization).
Compute shadow bias in the normal direction to avoid
both shadow leaking at certain angles or shadow
acnee.
This bias is computed automatically based on the minimum
bias amount required to remove all errors. The render
setting is removed as of no use for now.
#### Normal bias
We do the bias in world space instead of shadow space
for speed and simplicity. This requires us to bias using
the upper bound of biases for the same location in space
(using biggest texel world radius instead of UVZ bias).
This isn't much of an issue since the bias is still less
than 2 texel. The bias is still modulated by facing
ratio to the light so surfaces facing the light have no
biase.
This fixes both self shadowing and flat occluders aliasing
artifacts at the cost of moving the shadow a bit on the
side. This is the blue arrow in the diagram.
We always bias toward the normal direction instead of the
light direction. This is alike Cycles geometric offset for
the shadow terminator fix. This is better since it does'nt
modify the shading at all.
#### Slope bias
To avoid aliasing issue on zero slope receiver, we still
have to use the slope bias with a size of 1 pixel.
#### PCF filtering
We now parametrize the filter around the normal instead of
using the shadow map local space. This requires to use
a disk filter instead of box, which is also more pleasant
for most light shapes (all except rectangle lights).
Setting the filter around normal avoid overshadowing from
zero slope occluders. This cannot be fixed by more slope bias
in light space PCF. We could fix it in light space by projecting
onto the normal plane but that gives an unbounded bias when `N.L`
is near 0 which causes either missing shadows or self shadow if
using an arbitrary max offset value.
To avoid overshadowing from any surface behind the shading
point, we reflect the offset to always face the light.
Doing so instead of using the perpendicular direction
is better for very sharp geometric angles, has less
numerical precision issue, is symetrical and is cheaper.
To avoid any self shadowing artifact on zero slope receivers
with angled neighbors (like a wall and the floor), we have
to increase the slope bias according to the filter size.
This might be overkill in most situation but I don't feel
this should become a setting and should be kept in sync
with the filter. If it has to become an option, it should
simply a factor between unbiased filter and best bias.
#### Shadow terminator
The remaining artifacts are all related to shadow terminator
one way or another. It is always caused by the shading
normal we use for biasing and visibility computation not
being aligned with the geometric normal.
This is still something we need a setting for somewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/121088
This adds clamping at the light combine stage for both direct
and indirect light.
This allows for clamping direct and indirect light separately.
While direct light clamping might not be very desirable in
EEVEE, it might be wanted to reduce the flickering from distant
shiny bumpy surfaces, or for artistic reason.
This happens after applying the BSDF throughput just like cycles.
This is done in order to minimize the performance impact and
allows to split the clamp for direct light and indirect light.
The indirect light clamp value is still used in the ray-tracing
pipeline to clamp the ray intensity. But this differs from cycles
as we clamp the ray without the BSDF throughput here. Sphere probe
have the same issues. Some more energy loss is expected compared
to the direct light clamp.
Note that we still clamp the indirect light after applying BSDF
in case the BSDF is scaling the energy up above the threshold.
This also corrects the clamping for volume that now clamps after
applying the scattering term.
Also adds clamping to volume indirect lighting.
Since we use light probe volumes for both surface and volume
indirect lighting, we need to clamp them at sampling time.
Pull Request: https://projects.blender.org/blender/blender/pulls/120866
This is just adding a switch for enabling custom range.
Custom range is now optional as we compute a tight bound
to integrate around volume objects by default.
The custom range is only needed for scene with really
thick world volumes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120823
- Reorder panels to match Cycles (and rendering pipeline order)
`Sampling > Objects > Motion Blur / Dof > Film > Performance`
- General reordering of properties to avoid too many panels.
- Make sure panels a disabled if their checkbox is.
- Enabled Freestyle panel for EEVEE-Next.
- Merge some panels into sub-panels.
- Add `Clamping` panel.
- Split Lighprobe panel into `Performance` and `Scene`.
- Move shadow panel to Sampling.
- Generally improve consistency with Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/120691
Smooth transparent shadows by jittering their opacity threshold every
sample.
Always enabled on final renders, optionally enabled in the viewport with
`scene.eevee.shadow_jittered_transparency`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119480
This uses Spherical Harmonics to store the indirect lighting and
distant lighting visibility.
We can then reuse this information for each closure which divide
the cost of it by 2 or 3 in many cases, doing the scanning once.
The storage cost is higher than previous method, so we split the
resolution scaling to be independant of raytracing.
The spatial filtering has been split to its own pass for performance
reason. Upsampling now only uses 4 bilinearly interpolated samples
(instead of 9) using bilateral weights to avoid bleeding.
This also add a missing dot product (which soften the lighting
around corners) and fixes the blocky artifacts seen at lower
resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118924
A tone mapper designed specifically for PBR color accuracy, to get sRGB
colors in the output render that match as faithfully as possible the input
sRGB baseColor under gray-scale lighting. This is aimed toward product
photography use cases, where the scene is well-exposed and HDR color values
are mostly restricted to small specular highlights.
Fixes#118824: Proposal: add a view transform for Khronos PBR Neutral Tone Mapper
Co-authored-by: Emmett Lalish <elalish@google.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118936
