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
EEVEE-Next performes less on integrated GPUs then discrete GPUs.
Most shaders have been analyzed, but there will always be bottlenecks
related to architectural differences.
In order to make EEVEE-Next run smooth on integrated GPUs this change
will implement viewport pixel size option similar to Cycles. The main difference
is that the samples will still be weighted and up-sampled to the final film
resolution. This makes the pixels not look squared in the viewport but will
resolve to something close to the results without up-scaling.
This improves the performance especially on integrated GPUs. The improvement
for discrete GPUs are less noticeable. See here the stats when playing
`rain_restaurant.blend` back on a RAPHAEL_MENDOCINO iGPU.
| Pixel size | Frames per second |
|------------|-------------------|
| 1x | 0.25 FPS |
| 2x | 4.14 FPS |
| 4x | 6.90 FPS |
| 8x | 9.95 FPS |
Related to: #114597
See PR for some example images.
Pull Request: https://projects.blender.org/blender/blender/pulls/118903
Merge duplicated motion blur settings between Cycles and EEVEE,
and move them to `RenderData`/`scene.render`:
* `scene.cycles.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.use_motion_blur` -> `scene.render.user_motion_blur`
* `scene.eevee.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.motion_blur_shutter` -> `scene.render.motion_blur_shutter`
On the C/C++ side, this also renames `RenderData::blurfac` to
`RenderData::motion_blur_shutter`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117913
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
This adds option to bypass the raytracing pipeline
entirely and use a cheaper evaluation option.
This reuse the same evaluation as the Blended materials.
This exhibits some artifacts on Apple hardware due to
synchronization issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/116622
Before #108014, toggling "Auto Smooth" was an easy way to disable
evaluation of custom normals and face corner normals for faster
viewport playback performance. Now that corner normals are calculated
automatically as necessary, it's helpful to still have a way to disable
expensive normal computation for faster playback.
This commit adds a "Normals" scene simplify setting. To avoid a bunch
of complexity, it just influences which normals are requested from the
object by viewport rendering. In my tests, skipping calculating at
least doubled viewport FPS in a few test files with a large mesh with
custom normals. This works well because normals are cached and lazily
calculated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113975
- "Frame Step" -> "Number of frames to skip forward while baking each
frame": expand description which was just copying the prop name.
- "b-bone" -> "B-Bone": title case.
- "Volumes Lighting" -> "Volume Lighting": typo.
- "Volumes Shadows" -> "Volume Shadows": typo.
- "Insert Blank Keyframe (All Layer)" -> "(All Layers)": typo.
- "the an" -> "an", typo.
- "Inverse" -> "Invert": use verb instead of noun for an action.
- "Desination" -> "Destination": typo.
- "Hides all other F-Curves other than the ones being framed": remove
extra "other".
- "Remove Bone from Bone collections" -> "Collection", singular because
the operator is only applied to the active collection. Also title
case on "Collection".
- "Change Stroke material with selected material" -> "Assign the
active material slot to the selected strokes": rephrase by reusing
the message from the non-Grease Pencil materials.
- "VisAction", "VisArea" -> "Visibility Action", "Visibility Area":
expand abbreviation. This is not exposed in the UI right now but
will show up in the API docs.
- "Stop Mode Right / Global Down" -> "Stop Move" (typo).
- "... for node input %s": remove extra space.
- "Move along their normal" -> "Move shadows along their normal":
rephrase unclear sentence.
- "Stat Vis" -> "Mesh Analysis": stands for "Statistical
visualization"? Unclear and not shown anywhere. Reuse the label
specified in the UI code instead.
- " Output data...": remove leading space.
- "Attribute domain for the selection and group id inputs": title case
on "Selection" and "Group ID" as that is how they appear in the UI.
- "Ior" -> "IOR": uppercase acronym, for consistency.
Pull Request: https://projects.blender.org/blender/blender/pulls/115964
This de-duplicate some passes in the raytracing
pipeline and make it more ready for adoption
of arbitrary closure evaluation. This last part
means the removal of some per closure type
options.
The put in common the tile classification step
that is now done only once for all 3 closure
type. Also add some speedup to the tile
compaction phase that is now only twice
faster.
The horizon-scan setup was also de-duplicated
and run only if needed, which can save up to
0.5ms is complex scenes.
However, this moves the max-roughness and and
resolution scaling to a common parameter.
This is to be able to support arbitrary closure
evaluation where multiple closure with conflicting
parameters could be evaluated in one tracing pass.
Pull Request: https://projects.blender.org/blender/blender/pulls/116009
