This enables the new lazy module loading behavior introduced in OIDN 2.3,
without breaking compatibility with older versions of OIDN (using separate
code paths).
Also, the detection of OIDN support for devices is now much cleaner, and
devices do not need to be matched by PCI address or device name anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/121362
Change the preview size comparison threshold, so that we only use linear
interpolation for the render preview when zoomed out, and use nearest
neighbor interpolation at 1:1 zoom.
Pull Request: https://projects.blender.org/blender/blender/pulls/120325
This is an implementation of thin film iridescence in the Principled BSDF based on "A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence".
There are still several open topics that are left for future work:
- Currently, the thin film only affects dielectric Fresnel, not metallic. Properly specifying thin films on metals requires a proper conductive Fresnel term with complex IOR inputs, any attempt of trying to hack it into the F82 model we currently use for the Principled BSDF is fundamentally flawed. In the future, we'll add a node for proper conductive Fresnel, including thin films.
- The F0/F90 control is not very elegantly implemented right now. It fundamentally works, but enabling thin film while using a Specular Tint causes a jump in appearance since the models integrate it differently. Then again, thin film interference is a physical effect, so of course a non-physical tweak doesn't play nicely with it.
- The white point handling is currently quite crude. In short: The code computes XYZ values of the reflectance spectrum, but we'd need the XYZ values of the product of the reflectance spectrum and the neutral illuminant of the working color space. Currently, this is addressed by just dividing by the XYZ values of the illuminant, but it would be better to do a proper chromatic adaptation transform or to use the proper reference curves for the working space instead of the XYZ curves from the paper.
Pull Request: https://projects.blender.org/blender/blender/pulls/118477
This PR fixes the (currently unused) scene-based selective feature compilation macros. These feature based macros haven't been used for a few years, and enabling them currently results in compilation errors.
The only functional change in this PR is in geom/primitive.h where undef-ing `__HAIR__` had exposed an inconsistency in how pointcloud attributes were being fetched. Using the more general `primitive_surface_attribute_float4` (instead of `curve_attribute_float4`) fixed a compilation error that occurred when rendering pointcloud unit test scenes with adaptive compilation enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/121216
This PR replaces the existing CPU wall-clock based profiling mechanism with more precise GPU counter based timestamps. As before, it is enabled by setting the env var `CYCLES_METAL_PROFILING=1`. Original implementation by Morteza Mostajabodaveh.
Pull Request: https://projects.blender.org/blender/blender/pulls/121208
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
Clamp some of the inputs of the Glossy BSDF, Glass BSDF, Sheen BSDF,
and Subsurface Scattering nodes to improve consistency between render
engines and to avoid unexpected results.
* Clamp roughness to 0..1
* Clamp subsurface radius to 0..inf
* Clamp colors to 0..inf
Pull Request: https://projects.blender.org/blender/blender/pulls/120390
This replaces the fixed Tangent input in BsdfNode::compile
with a custom input.
This is done because very few nodes actually use the tangent input
and it would be better to have this slot available for other inputs
on different nodes in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/119042
The slowdown was caused by the volume step calculation returning an
infinite value. This was caused by the calculation happening before
the object bounds are calculated via the code path which does some
early update for the displacement and hair transparency. The actual
value was never re-calculated after bounds are valid.
The solution is to only clear need-update after the final call of
the device_update_flags().
Pull Request: https://projects.blender.org/blender/blender/pulls/121042
Support for building blender with clang on windows on x64 was added
years ago but given there are no active users support has crumbled a
bit.
This PR brings the build system back into working order but upstream
patches in openVDB are still required for a successful build see PR
#120317 for details.
Blender when build with clang the classroom scenes rendered on the cpu
with cycles is seeing a 5% reduction in render time on both an
AMD 7700x and an Intel 14900k.
by ensuring `KernelLight.lightgroup` is properly assigned in
`device_update_light()`. The value is later retrieved via
`lamp_lightgroup(kg, lamp)`.
`light_manager->device_update()` is called after
`background->device_update()`, so the background light group should
already been assigned when `device_update_lights()` is called.
Pull Request: https://projects.blender.org/blender/blender/pulls/120714
use available `film_pass_pixel_render_buffer()` to access the pointer
to the render buffer.
For shadow state, a similar function `film_pass_pixel_render_buffer_shadow()`
is created, because `shadow_path` instead of `path` is needed.
it is difficult to keep in mind when MIS weight is needed, better to
handle this logic in the lower-level functions.
This reduces code duplication in many places.
The problem here was that `free_data_after_sync` frees the particle cache in headless or locked-UI mode, but the second view doesn't regenerate them.
For multi-view renders, dropping caches is a tradeoff between compute and memory - dropping allows to reduce peak memory usage, but requires recomputation for the next view. With the current design however, dropping is not something that is easily achievable anyways (see the referenced bugs). So until something more reliable and better fitting is implemented, keep the data from Blender side until the last view.
Since `free_data_after_sync` doesn't do anything for baking or viewport renders anyways, it's easiest to just move this out into `BlenderSession::render` since that already checks whether another view is still outstanding.
Also fixes#73221 and #107589.
Pull Request: https://projects.blender.org/blender/blender/pulls/120543
get_apple_gpu_architecture will now report if the GPU being checked
is not an Apple GPU.
At the moment this has no functional changes. But it reduces the
chances of mistakes in the future where a developer tries to enable
a feature on newer Apple GPUs using get_apple_gpu_architecture,
and accidentally enables it on unsupported AMD and Intel GPUs.
Pull Request: https://projects.blender.org/blender/blender/pulls/120448
With the switch to using the primary CUDA context it became possible
for peer access between CUDA devices to already have been enabled for
that context, either by a previous Cycles session or third-party library,
thus causing the call to `cuCtxEnablePeerAccess` to return
`CUDA_ERROR_PEER_ACCESS_ALREADY_ENABLED`. This is not a failure
state however, so just needs to be handled like a success return value.
Pull Request: https://projects.blender.org/blender/blender/pulls/120255
Extract
- Statuses for the external text editor
- Newly created enum node item
- Newly created plane track data
- Newly created custom orientation data
- Operator names in drag and drop menu (need to use operator's
translation context)
- GN attribute statistic node inputs
Disambiguate
- Single-letter colors: A and B can mean Alpha and Blue, or simply A
and B as in two operands in an operation
- Dissolve: issue reported by Tamar Mebonia in #43295
- Translate in the User Preferences. This introduces a new
BLT_I18NCONTEXT_EDITOR_PREFERENCES ("Preferences") translation
context
- Planar (reported by deathblood)
This one is incomplete, because there is currently no way to
disambiguate presets or GN fields. I don't see how either could be
achieved cleanly.
The former would need to define the context inside the preset and
evaluate the file prior to showing it in the presets menu, which
sound bad.
The latter would need to introduce an additional string inside
`FieldInput`s, which would be controversial given how little it
would be used.
Remove
- Unused translation `iface_("%s")` in toolbar
- Remove obsolete N_() tags in a few node descriptions.
Pull Request: https://projects.blender.org/blender/blender/pulls/119065
This is a regression since fdc2962beb
The size of state can not be different between CPU and GPU.
This change replaces compile-time condition with a kernel feature
check, which solves the render regression on AMD Metal. It also
minimizes the state size on other GPUs when Light Tree is disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/120476
Ever since commit [1], `use_metalrt_by_default` will be True
if the GPU being used is not a M1 or M2 based system.
The intention of this was to enable MetalRT by default for
M3 and newer devices that have hardware for ray traversal.
However the side effect of this change was that all AMD GPUs would
have `use_metalrt_by_default` set to True. Which appears to be the
main culprit causing crashes on older AMD GPUs in #120126.
Since these GPUs don't support MetalRT.
This commit fixes this issue by only setting
`use_metalrt_by_default` to True if the GPU is not M1 or M2 based,
and the GPU is Apple Silicon based. Which equates to M3 or newer.
Which is the original intent of this code.
This resolves the issue where AMD GPUs were being told to use MetalRT
by default, when they shouldn't be.
[1] 322a2f7b12
Pull Request: https://projects.blender.org/blender/blender/pulls/120299
The issue was caused by the special code in Cycles which clears object
caches when it thinks they are not needed. We should not free caches of
grease pencils because it is needed later by a separate render engine.
Pull Request: https://projects.blender.org/blender/blender/pulls/120315
This is a regression in 4.1, caused by 36e603c430.
For unbiased MIS weight in light tree, we should use sd->N for
mis_origin_n, since sc->N is not available in NEE.
The change also makes it so we do not sample lights below sd->N even
when bump map correction is disabled. This diverges from the original
idea of giving full control to artists, but ensures the internal math
is happy.
Pull Request: https://projects.blender.org/blender/blender/pulls/120216
fdc2962beb indirectly introduced a change
in inlining (light_tree_pdf started getting inlined) that led to a 5-10%
drop in performance for most scenes.
Dropping the noinline keyword for oneAPI device recovers it.
It however brings another performance regression to MNEE and Raytrace
kernels, that we'll look into separately.
The Perlin noise algorithms suffer from precision issues when a coordinate
is greater than about 250000.
To fix this the Perlin noise texture is repeated every 100000 on each axis.
This causes discontinuities every 100000, however at such scales this
usually shouldn't be noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/119884
it is not clear from which point the `cos_theta_u` should be computed in
volume segment, so the original implementation was mixing the closest point
and the point where the minimal angle is formed.
Use the closest point on segment as a conservative measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/119965
in the test scene `all_light_types_in_volume.blend`, `theta - theta_o -
theta_u` is slightly above the threshold. Even if we do a strict check
with `acos` on the failing cases, it will go to the other branch and
deliver a result which is also 1.0f. Better to relax the threshold.
Cycles samples environment map with a PDF proportional to the luminance.
This computation was assuming positive values, but generated texture
coordinates from world could have negative values, so the resulted CDF
was almost zero in the bug report scene.
Fixed by taking the absolute value when computing luminance in CDF.
Pull Request: https://projects.blender.org/blender/blender/pulls/119896
During the some of the shading for volumetrics, Cycles would try to
write to a variable that does not exist if the device has the
light tree disabled.
At the moment this only impacts AMD GPUs with the Metal backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/119906
