Cycles implements the "Taming the Shadow Terminator" paper by Matt Jen-Yuan
Chiang to solve shadow terminator issues when a bump map is applied, as well
as similar approach for the glossy reflection to ensure ray does not get
reflected to inside of the object.
This correction term is applied unconditionally, which makes it harder to have
full control over shading via normals for stylistic reasons.
This change exposes this corrective term as an option called "Bump Map
Correction" which is available in the shader settings next to the
"Transparent Shadows".
The reason to make it per-shader rather than per-object is to allow flexibility
of a control: it is possible that an object has multiple shaders attached to it,
and only some of them used for bump mapping. Another, and possibly stronger
reason to have it per-shader is ease of assets control: shader brings settings
which are needed for its proper behavior. So if material at some point
decides to take over normals, artists would not need to update settings on
every asset which uses that material.
The option is enabled by default, so there is no changes for existing setups.
Pull Request: https://projects.blender.org/blender/blender/pulls/113480
The first public Windows driver version with a higher number is
101.4824, so we bump the min-required driver version on Windows to this
one to ensure compatibility.
This patch updates the experimental MetalRT code path to use new [curve primitives](https://developer.apple.com/videos/play/wwdc2023/10128/) which were recently added in macOS 14. This replaces the previous custom box intersection implementation, allowing the driver to better optimise curve acceleration structures for the GPU. On existing hardware, this can speed up MetalRT renders by up to 40% for scenes that use hair / curve primitives extensively.
The MetalRT option will only be available on macOS >= 14, and requires Xcode >= 15 to build (otherwise the option will be compiled out).
Authored by Marco Giordano, Michael Jones, and Jason Fielder
---
Before / after render times (M1 Max MacBook Pro, macOS 14 beta, MetalRT enabled):
```
Custom box intersection MetalRT curve primitives Speedup
fishy_cat 111.5 80.5 1.39
koro 114.4 86.7 1.32
sinosauropteryx 291.8 279.2 1.05
spring 142.3 142.2 1.00
victor 442.7 347.7 1.27
```
---
Pull Request: https://projects.blender.org/blender/blender/pulls/111795
This is in prevision of EEVEE panoramic projection support.
EEVEE-Next is planned to add support for these parameters.
Not having these parameters in Blender DNA will make Cycles
and EEVEE not share the same parameters and will be confusing
for the user.
We handle forward compatibility by still writing the parameters
as ID properties as previous cycles versions expect.
Since this change will break the API compatibility it is crucial
to make it for the 4.0 release.
Related Task #109639
Pull Request: https://projects.blender.org/blender/blender/pulls/111310
- "Front"/"Back": 'put something at the front/back' or 'the front/back
face of something'. (e. g. the Empty Image options, Depth and Side
option, both use the same strings as enum, which should be avoided
in some languages).
- "Flip": invert, as in normals, or mirror, as in an image.
- "Path": a path to a resource, in general a file but sometimes a
datablock, as opposed to a trajectory in space.
- "Join": disambiguate for the Grease Pencil operator, which may use a
different word as that for meshes.
- "Wave": an ondulating motion, as opposed to a fluid dynamics motion.
- "Step": can mean the distance between two things, or a number of
times to do something. In this case it is better to use the plural.
- "Edge": generally the edges of a mesh, but can also mean edge
detection. Additionally, it was used for the option to enable
Freestyle. This was changed to "Use Freestyle".
- "Boundary": the limit of a grease pencil drawing for filling
purposes, as opposed to the external limit of a (non-manifold) mesh.
- "Rotations": can be translated to something like "Turns", in the
context of a spiral.
Pull Request: https://projects.blender.org/blender/blender/pulls/108213
During recent testing, the oldest 101.4032 (windows) and <25812 (linux)
drivers led to crashes during JIT compilation, so we bump the
requirement to newer 101.4313 and 25812.14 drivers that do incorporate
the required fixes.
Pull Request: https://projects.blender.org/blender/blender/pulls/109281
HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a
to shader implementation for older graphics cards. It offers an average 25%
sample rendering rate improvement in Cycles benchmarks, on a W6800 card.
The ray tracing feature functions are accessed through HIP RT SDK, available on
GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and
shipped with the SDK.
This is not yet enabled as there are issues to be resolved, but landing the
code now makes testing and further changes easier.
Known limitations:
* Not working yet with current public AMD drivers.
* Visual artifact in motion blur.
* One of the buffers allocated for traversal has a static size. Allocating it
dynamically would reduce memory usage.
* This is for Windows only currently, no Linux support.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
Using the new HIP SDK 5.5 that includes a fix for the compiler bug.
This also enables the light tree.
For Linux the binaries are still disabled. ROCm 5.5 is planned to
include the same fix but not released yet. When that happens we
should be able to enable Linux as well.
Ref #104786Fix#104085
Pull Request: https://projects.blender.org/blender/blender/pulls/107098
Updated Embree 4 library with GPU support is required for it to be
compiled - compatiblity with Embree 3 and Embree 4 without GPU support
is maintained.
Enabling hardware raytracing is an opt-in user setting for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/106266
Some UI functions have a "translate" argument, which if set to False
specifies that the message is not to be translated. This sometimes
means that it was already translated beforehands.
But many messages were still getting extracted, sometimes twice in
different contexts. Some featured errors because the arguments of
various functions would be concatenated, such as:
```
col.label(text=iface_("Branch: %s") % bpy.app.build_branch.decode('utf-8', 'replace'), translate=False)
```
which would get extracted as:
```
msgid "Branch: %sutf-8replace"
```
Pull Request #105417
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
The internal compiler error appears to be gone. Unclear why it appeared in the
first place and why it's gone now. Just random kernel code changes causing it.
Pull Request #104719
The required version numbers for various devices was hardcoded in the
UI messages. The result was that every time one of these versions was
bumped, every language team had to update the message in question.
Instead, the version numbers can be extracted, and injected into the
error messages using string formatting so that translation updates
need happen less frequently.
Pull Request #104488
A noticeable (>5%) performance regression in oneAPI backend came with
a501a2dbff. Updating to latest graphics
compiler from driver 101.4032 fixes it.
I've tested it with current min-supported drivers and it runs well but
since compatibility of graphics compiler with older drivers isn't
guaranteed, I'm also bumping the min-supported driver versions.
If end-users consider latest drivers too fresh to switch to (version
isn't released as stable on Linux as of today but should be before
Blender 3.5 release), CYCLES_ONEAPI_ALL_DEVICES=1 env variable can be
used.
Intel Graphics Compiler on Linux will be updated in a later commit
so we can then close D16984.
Reviewed By: sergey, LazyDodo
While keeping SSE2, SSE4.1 and AVX2. This does not affect hardware support, it
only slightly reduces performance for some older CPUs.
To reduce maintenance cost and improve compile times.
Differential Revision: https://developer.blender.org/D16978
This patch adds a new "Kernel Optimization Level" dropdown menu to control Metal kernel specialisation. Currently this defaults to "full" optimisation, on the assumption that the changes proposed in D16371 will address usability concerns around app responsiveness and shader cache housekeeping.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16514
The first two dimensions of scrambled, shuffled Sobol and shuffled PMJ02 are
equivalent, so this makes no real difference for the first two dimensions.
But Sobol allows us to naturally extend to more dimensions.
Pretabulated Sobol is now always used, and the sampling pattern settings is now
only available as a debug option.
This in turn allows the following two things (also implemented):
* Use proper 3D samples for combined lens + motion blur sampling. This
notably reduces the noise on objects that are simultaneously out-of-focus
and motion blurred.
* Use proper 3D samples for combined light selection + light sampling.
Cycles was already doing something clever here with 2D samples, but using
3D samples is more straightforward and avoids overloading one of the
dimensions.
In the future this will also allow for proper sampling of e.g. volumetric
light sources and other things that may need three or four dimensions.
Differential Revision: https://developer.blender.org/D16443
Improve a few messages, but mostly fix typos in many areas of the UI.
See inline comments in the differential revisiion for the rationale
behind the various changes.
Differential Revision: https://developer.blender.org/D16716
Uses a light tree to more effectively sample scenes with many lights. This can
significantly reduce noise, at the cost of a somewhat longer render time per
sample.
Light tree sampling is enabled by default. It can be disabled in the Sampling >
Lights panel. Scenes using light clamping or ray visibility tricks may render
different as these are biased techniques that depend on the sampling strategy.
The implementation is currently disabled on AMD HIP. This is planned to be fixed
before the release.
Implementation by Jeffrey Liu, Weizhen Huang, Alaska and Brecht Van Lommel.
Ref T77889
This was not working well in non-trivial scenes before the light tree, and now
it is even harder to make it work well with the light tree. It would average the
with equal weight for every light object regardless of intensity or distance, and
be quite noisy due to not working with multiple importance sampling.
We may restore this if were enough good use cases for the previous implementation,
but let's wait and see what the feedback is.
Some uses cases for this have been replaced by the shadow catcher passes, which
did not exist when this was added.
Ref T77889
Materials now have an enum to set the emission sampling method, to be
either None, Auto, Front, Back or Front & Back. This replace the
previous "Multiple Importance Sample" option.
Auto is the new default, and uses a heuristic to estimate the emitted
light intensity to determine of the mesh should be considered as a light
for sampling. Shaders sometimes have a bit of emission but treating them
as a light source is not worth the memory/performance overhead.
The Front/Back settings are not important yet, but will help when a
light tree is added. In that case setting emission to Front only on
closed meshes can help ignore emission from inside the mesh interior that
does not contribute anything.
Includes contributions by Brecht Van Lommel and Alaska.
Ref T77889
This patch generalizes the OSL support in Cycles to include GPU
device types and adds an implementation for that in the OptiX
device. There are some caveats still, including simplified texturing
due to lack of OIIO on the GPU and a few missing OSL intrinsics.
Note that this is incomplete and missing an update to the OSL
library before being enabled! The implementation is already
committed now to simplify further development.
Maniphest Tasks: T101222
Differential Revision: https://developer.blender.org/D15902
This can be used for example for VR video formats that use this projection
instead of perspective projection for cubemap faces.
Differential Revision: https://developer.blender.org/D13525
Intel documentation for Ubuntu 22.04 does list all runtime components
needed by the driver and oneAPI Cycles device but end-users getting
drivers from (other) sources can easily end-up missing required
Level-Zero Loader and struggle root causing what's wrong in their
system. Calling this requirement out in the UI will hopefull help them.
oneAPI Level-Zero incl. Loader: https://github.com/oneapi-src/level-zero
Common package names: level-zero, level-zero-loader
This adds path guiding features into Cycles by integrating Intel's Open Path
Guiding Library. It can be enabled in the Sampling > Path Guiding panel in the
render properties.
This feature helps reduce noise in scenes where finding a path to light is
difficult for regular path tracing.
The current implementation supports guiding directional sampling decisions on
surfaces, when the material contains a least one diffuse component, and in
volumes with isotropic and anisotropic Henyey-Greenstein phase functions.
On surfaces, the guided sampling decision is proportional to the product of
the incident radiance and the normal-oriented cosine lobe and in volumes it
is proportional to the product of the incident radiance and the phase function.
The incident radiance field of a scene is learned and updated during rendering
after each per-frame rendering iteration/progression.
At the moment, path guiding is only supported by the CPU backend. Support for
GPU backends will be added in future versions of OpenPGL.
Ref T92571
Differential Revision: https://developer.blender.org/D15286
Windows drivers 101.3430 fix an important GUI-related crash and it's
best to prevent users from running into it.
Linux drivers weren't affected but still had relevant gpu binary
compatibility fixes, so it makes sense to keep the min-supported version
aligned across OSes.
The multi-dimensional Sobol pattern required us to carefully use as low
dimensions as possible, as quality goes down in higher dimensions. Now that we
have two sampling patterns that are at least as good, there is no need to keep
it around and the implementation can be simplified.
Differential Revision: https://developer.blender.org/D15788
sycl/L0 runtime reports compute-runtime version since Intel graphics
driver 101.3268 on Windows, when querying driver version from sycl.
Prior to this driver, it was 0. Now we can bump minimum requirement to
this one and filter-out devices returning 0.
Maniphest Tasks: T100648
