This adds the `UILayout::property_split_factor` property which contains
the split factor used in the layout system, and avoids to use the this
as raw value all over the place.
Pull Request: https://projects.blender.org/blender/blender/pulls/163393
Many UI messages are extracted from the OpenColorIO config, including
color spaces and families, displays, views, view transforms, and
looks.
The risk of a translation collision between these data and other
messages is quite high, especially if using an OCIO config other than
the built-in one.
This commit changes extraction and translation so that all these
strings are translated with the new "Color Management" translation
context. It does not reuse the existing "Color" context, in the
unlikely event of a collision with other color-related stuff in the
UI.
Suggested by Bastien Montagne while reviewing !160883.
Pull Request: https://projects.blender.org/blender/blender/pulls/161053
A `time_limit` option analogous to that offered by Cycles is added to
EEVEE. Like for Cycles, it is disabled when set to zero.
Furthermore, info logging of the rendered samples and the render time
is added.
Pull Request: https://projects.blender.org/blender/blender/pulls/160169
Instead of reusing `ERROR` for both warnings and errors, and the Info
Editor icon for "info" label comments, use the new icons from !161002.
* Use `STATUS_WARNING` when the code refers to simple warnings, the
feature might still work.
* Use `STATUS_ERROR` when the code refers to incompatibility, broken
functionality, general errors.
* Use `STATUS_INFO` for every info label. Keep `INFO` for the editor.
* Sometimes `WARNING_LARGE` was used, that should only be used for
dialogs. Use the regular warning instead, it looks almost the same.
* When extra contrast is needed, the filled version is used.
Mostly no big visual changes, other than warnings that were meant as
actual errors using the proper icon now.
See !161038 for details and screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/161038
This improves the thickness heuristic of Screen Space
Raytracing, Fast GI, AO, and Raycast Node.
It changes the behavior of the thickness sliders, likely
changing the look of existing scene.
The Fast GI Approximation > Far Thickness is removed.
See Pull Request for more details.
Pull Request: https://projects.blender.org/blender/blender/pulls/157763
This is a scene wide option to choose backface hit behavior
for screen tracing. This allows more control of the look
of the Global Illumination.
Backface hits are defined as hitting the camera facing
geometry from behind.
The option is a slider that allows to reuse part of the
front-face radiance as backface indirect lighting
contribution.
Not considering rays hitting backfaces as "missed" ray
most of the light leaking that can happen when using
Screen Space Global Illumination.
The option can be turned off all-together using the checkbox
for compatibility reasons. Turning it off will recover the
same "ray fail" behavior of the previous version.
Note that this patch modifies what is treated as a backface hit.
The previous definition could return true on ray going away
from the viewer, which was incorrect. This fixes small patches
of missing hits next to depth discontinuities. This is why
one test needed to be updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/157803
When user changes backend to OpenGL while having HDR display selected,
"HDR display not supported" message is displayed, which may lead to
unnecessary debugging of this issue.
In case of #157720, the backend was changed presumably when user saved
factory settings and did not realize that backend would be changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/157729
Use the family and description for the OpenColorIO config to organize
colorspaces into hierarchical menus, rather than having a long list.
The code is provided following the Corporate Contributor License
Agreement signed between Stichting Blender Foundation and
Lucasfilm Entertainment Company Ltd. LLC.
Resolves#112568
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/151678
This PR adds a render engine specific quality setting for anisotropic
filtering. The User preference option is still used in other places
(Clip editor, sampling, ...).
The implementation generates all sampler permutation and select the one
that is needed on a per case base. When building the GPU material from
the shader graph anisotropic filtering can be requested by setting the
`GPU_SAMPLER_FILTERING_ANISOTROPIC_ENABLE` flag. When generating the
draw pass for the material, the sampler is being updated to match
`scene.render.anisotropic_filter`.
Pull Request: https://projects.blender.org/blender/blender/pulls/155111
#### This patch adds **Direct** and **Indirect Light intensity controls** to **EEVEE**.
The new controls allow artists to scale the contribution of **direct** and **indirect**
lighting paths independently, without modifying the underlying lighting algorithms,
sampling, or ray tracing settings.
Both controls default to `1.0`, resulting in **no visual change** for existing files.
### Design Rationale
This feature is intentionally narrow in scope and exists to address cases that cannot
be handled correctly or efficiently using render passes or the compositor.
A compositor-based solution is currently not viable because Direct and Indirect light
passes **do not yet exist**, and when they do, they will not support **blended materials**.
This would create discrepancies between **dithered** and **blended** materials.
Using render passes for this purpose would also require additional accumulation passes
and buffers, would not be compatible with `TAA`, and would be disproportionate to a simple
scalar operation. For these reasons, the controls are implemented directly in the EEVEE
lighting pipeline.
The scaling is applied after clamping to preserve firefly suppression behavior and to
match the **behavior** of a **post-lighting compositing** adjustment.
### Intended Use
In spirit, this is similar to *Light Probe intensity* and is useful for:
- Large-scale environments where lighting balance needs adjustment
- Scenes requiring stronger or weaker indirect illumination
- Balancing direct vs indirect contribution without reauthoring lights
- HDR and color grading workflows
The controls do **not** alter ray depth, sampling, accumulation, or performance
characteristics, and apply uniformly across the EEVEE lighting paths.
Pull Request: https://projects.blender.org/blender/blender/pulls/153340
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
