These are now included in the OSL shared libraries, so no reason to
link against it.
The CMake code for WITH_LLVM remains in case it is useful in the future,
but is not enabled by any Blender feature now.
Pull Request: https://projects.blender.org/blender/blender/pulls/118229
Turns out we were not building OSL with OptiX enabled anymore.
Also check now if the OSL builds has OptiX support and if not
disable it in Cycles.
Building OSL with support for this (still) does not require
either the OptiX SDK or CUDA, it only needs LLVM.
Pull Request: https://projects.blender.org/blender/blender/pulls/118234
Currently the multi-input sockets are not exposed to the custom nodes
Python API. This makes some features cumbersome to implement if one
wants a node to process an arbitrary number of inputs.
One workaround is to make inputs duplicate themselves when a link is
created, but a proper multi-input would be easier to use for both
add-on developers and users.
This commit exposes a new `use_multi_input` boolean parameter when
creating a new node socket. This makes it possible to declare a
multi-input, while still leaving the existing `is_multi_input`
property read-only so that existing nodes cannot be made unstable.
The parameter is optional so existing scripts stay compatible. It also
raises an error when used on output sockets, since it makes no sense
for those to be multi-input.
The Custom Node Tree Python template was updated to reflect this
change by making one of the inputs of the custom node multi-input.
Pull Request: https://projects.blender.org/blender/blender/pulls/114474
This commit updates all defines, compiler flags and cleans up some code for unused CPU capabilities.
There should be no functional change, unless it's run on a CPU that supports sse41 but not sse42. It will fallback to the SSE2 kernel in this case.
In preparation for the new SSE4.2 minimum in Blender 4.2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118043
This feature is useful for many production scenarios as it allows for the
creation of separate render passes with specific worlds. This would help
workflows that require different skies or other backgrounds for compositing.
Ref #117919
Pull Request: https://projects.blender.org/blender/blender/pulls/117920
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
Add new "Soft Falloff" option on point and spot light that uses
the old light behavior from Blender versions before 4.0. Blend
files saved with those older versions will use the option.
This option is enabled by default on new lights.
Fix#114241
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/117832
- Incorrect accurate prefiltering of albedo and normal (lower than expected quality)
- Changing the prefiltering mode has no immediate effect
- Default memory limit is too high (more than OIDN default)
- Memory limit is applied only to the main filter
- Quality setting applied only to the main filter
Pull Request: https://projects.blender.org/blender/blender/pulls/117930
This is supported on Apple Silicon GPUs and macOS 13.0+.
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
Co-authored-by: Attila Afra <attila.t.afra@intel.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/116124
OpenImageDenoise API exposes two modes, high quality and balanced.
This currently only has effect on Nvidia devices, on which it
provides a noticeable performance improvement without visible
difference in quality. This change sets quality to balanced for
the viewport, and high quality for final frame rendering, as
it's what makes the most sense.
Ref #115045
Co-authored-by: Werner, Stefan <stefan.werner@intel.com>
Pull Request: #115265
HWRT checkboxes visibility in the Cycles settings wasn't uniform across devices.
With this change, we unify it and gray out these in case HWRT isn't available.
Pull Request: https://projects.blender.org/blender/blender/pulls/117904
This is a leftover from when there was a global option for transparent
shadows, but since it's now per material this makes no sense anymore.
Solution found by Olivier Maury.
Pull Request: https://projects.blender.org/blender/blender/pulls/117735
With drivers 101.4972 to 101.5085, some Arc and Meteor Lake devices
ignore the prebuilt GPU binaries and since the addition of Meteor Lake
binaries, fail caching newly generated ones on Windows.
This got fixed in drivers 101.5186 so it's preferable to require these
new drivers to be used.
This allows users to turn off reflective and refractive caustics
separately from each other when using the Generalized Schlick material.
This will impact the Principled BSDF and Glass BSDF, along with some
custom OSL scripts.
Pull Request: https://projects.blender.org/blender/blender/pulls/117617
Seems to be a fairly niche type, but some people (apparently mostly in the automotive space) use it.
Also improves the handling of IES files in general and lets Cycles accept IES files that are technically violating the spec - which seems to be most of them...
Pull Request: https://projects.blender.org/blender/blender/pulls/114689
Improve the handling of Principled BSDF Caustics from Metallic
and Transmissive components, improving consistency between SVM and OSL,
and offering more predictable results.
Pull Request: https://projects.blender.org/blender/blender/pulls/115081
While investigating Blender compilation time for windows-arm64, we
identified two compilation units that were taking a long time to compile
(~1h each). This affects windows-x64 builds as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/117534
This changes fixes the slowdown when baking data passes like Normal with
the denoiser enabled on scene settings.
When baking to 4K textures denoising could take considerable amount of
time, which is better be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/117483
Cycles can use a per face flag to determine if a face is smooth or flat,
and there is no need to use corner normals in such cases. So revert to
not doing that as before, which also saves a bit of memory.
There is a pre-existing issue where faces are split by sharp edges and
autosmooth, which is not solved by this. It's only fixing the regression.
The pre-4.0 Principled BSDF had a special diffuse BSDF that contained
the roughness value from the node. Since 4.0, the regular Diffuse BSDF is used,
so we need to ignore it when determining the roughness value for baking.
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
Fixes an issue where CPU specific render settings (e.g. path guiding)
would be hidden when GPU Compute has been selected for rendering,
but a GPU hasn't been selected in preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116123
In this case the object transform can use more motion steps, but the
geometry needs to have its motion steps fixed since the velocity
attribute completely overrides them.
There was one functional issue with the previous API which was its
use in `VolumeGrid<T>::grid_for_write(tree_token)`. The issue was
that the tree token had to be received before the grid is accessed.
However, this `grid_for_write` method might create a copy of the
`VolumeGridData` internally and if it does, the passed in `tree_token`
corresponds to the wrong tree.
The solution is to output the token as part of the method. This has two
additional benefits:
* The API is more safe, because one can't pass an r-value into the methods
anymore. This generally shouldn't be done, because the token should
live at least as long as the OpenVDB tree is used and shouldn't be freed
immediatly.
* The API is a bit simpler, because it's not necessary to call the
`VolumeGrid.tree_access_token()` method anymore.
When a mesh light is shadow-linked to something with a specific
shader network it was possible that the emission_sd_storage was
not bit enough for sampling.
The shade_dedicate_light kernel only evaluates emission of either
light or mesh emitter and then resumes the regular path tracer.
There is no need to store closures.
This change makes it so a smaller storage is used, and also
passes flag to the shader evaluation function indicating that
closures are not to be stored.
Pull Request: https://projects.blender.org/blender/blender/pulls/116907
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
ROCm 6 brings some changes to the HIP API. This pull request is meant to be
backward and forward compatible.
That is Blender could be compiled with either ROCM 6 or 5 and run on either.
The main change is the hipMemoryType enum, which we check based on the
runtime version to use the correct enum values.
Without this, HIP will not work on Windows with upcoming 23.40 driver.
Pull Request: https://projects.blender.org/blender/blender/pulls/116713
The IES parser in Cycles would lead to heap buffer overflow error
when non-supported or invalid data is provided to it.
The error was caused by the way how stirng is copied to vector
skipping the last null-terminator. Later C-style string utilities
are used for parsing, and they expect the data to be null-terminated.
It is unclear why data needs to be stored as vector: storing it as
string simplifies initialization.
Easiest to reproduce the issue is to use Blender build with address
sanitizer enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/116752
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Fix issues related to NaN normals in some situations by trying
to detect when these cases might occur and just reverting back
to default normals.
As a side effect of these changes, OSL now behaves correctly
when given a non-normalized normal.
Pull Request: https://projects.blender.org/blender/blender/pulls/114960
Fixes an issue where triangles (and possibly lights) would not be added
to the light tree if the only visibility option it has enabled is volumetric
scattering.
This would lead to an assert during forward sampling because the light
would be treated as if it was in the light tree, and a light index
outside the light tree array would be sampled, which would trigger
the assert.
Pull Request: https://projects.blender.org/blender/blender/pulls/116703
Some common headers were including this. Separating the includes
will ideally lead to better conceptual separation between CustomData
and the attribute API too. Mostly the change is adding the file to
places where it was included indirectly before. But some code is
shuffled around to hopefully better places as well.
Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This refactors how volume grids are stored with the following new goals in mind:
* Get a **stand-alone volume grid** data structure that can be used by geometry nodes.
Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block.
* Support **implicit sharing of grids and trees**. Previously, it was possible to share data
when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was
not flexible enough.
* Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls
to some "load" function all the time.
* Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block.
* Get a **tiered API** for different levels of `openvdb` involvement:
* No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that
still work in this case. This makes it possible to write high level code for volumes that does
not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`.
* Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care
is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as
much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`.
* "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned
out to be not necessary for the common API. So this is only used for task specific APIs.
At the core of the new API is the `VolumeGridData` type. It's a wrapper around an
`openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading.
Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid.
Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit
sharing. At highest level we currently have the `Volume` data-block which contains a list of
`VolumeGrid`.
```mermaid
flowchart LR
Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid
```
The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes
it easy to load and reuse entire files and individual grids from disk. It also supports caching
simplify levels for grids on disk.
An important new concept are the "tree access tokens". Whenever some code wants to work
with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`.
This access token has to be kept alive for as long as the code works with the grid data. The same
token is valid for read and write access. The purpose of these access tokens is to make it possible
to detect when some code is currently working with the openvdb tree. This allows freeing it if it's
possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by
multiple owners, but only no one is actively working with. In some sense, this is similar to the
existing `ImageUser` concept.
The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`.
Most other changes are updates to existing code to use the new API.
Pull Request: https://projects.blender.org/blender/blender/pulls/116315
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
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
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
This was required for OSL, which used to be compiled entirely without
RTTI for LLVM. However OSL now only compiles a private part of its code
without RTTI, so this no longer necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/116035
The NanoVDB headers are not compatible with Metal due to missing address
space qualifiers. We currently have a big patch for NanoVDB header
files, which is difficult to update for OpenVDB 11. Instead extract a
few hundred lines of code from NanoVDB to do just what we need.
Pull Request: https://projects.blender.org/blender/blender/pulls/115992
This makes the GPU tricubic implementation more efficient. The dense
grid code implemented this in terms of trilinear lookups that are
hardware accelerated, but for NanoVDB this just causes unnecessary voxel
reads. Instead match the CPU code.
Pull Request: https://projects.blender.org/blender/blender/pulls/115992
There's already a queue from the Cycles rendering device, so let OIDN use the same instead of creating a new one.
Co-authored-by: Werner, Stefan <stefan.werner@intel.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115650
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
While this code is suspect, better to go back to the old state for now,
as there is no simple fix that doesn't introduce other issues.
Fix#115022Fix#115414
This reverts commit 063a9e8964.
Fixes an issue where the sheen would render incorrectly when
the normal of the surface is parallel to the incoming direction.
Co-authored-by: Lukas Stockner <lukas.stockner@freenet.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/115286
OpenImageDenoise has two modes, high quality and balanced. This now exposes the modes as user parameters, with viewport denoising defaulting to balanced and final frame rendering set to high quality.
Ref #115045
Co-authored-by: Werner, Stefan <stefan.werner@intel.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115265
The side effect which wasn't that obvious from the documentation
is that tasks in the console pool are executed sequentially. This
made the compile-gpu step to take a long time, because the parallel
compilation got disabled.
That was unintended change, so reverting the change.
Instead, for the buildbot, increase the time limit for the step.
This reverts commit 4b891b4afe.
This add the displacement option to EEVEE materials.
This unifies the option for Cycles and EEVEE.
The displacement only option is not matching cycles
and not particularly useful. So we decided to not
support it and revert to displacement + bump.
Pull Request: https://projects.blender.org/blender/blender/pulls/113979
OpenImageDenoise V2 comes with GPU support for various backends. This adds a new class, OIDNDenoiserGPU, in order to add this functionality into the existing Cycles post processing pipeline without having to change it much. OptiX and OIDN CPU denoising remain as they are. Rendering on a supported Intel GPU will automatically select the GPU denoiser.
Device support is initially limited to the oneAPI devices that are supported by Cycles, but can be extended.
Ref #115045
Co-authored-by: Stefan Werner <stefan.werner@intel.com>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/108314
This path merges the Musgrave and Noise Texture nodes into a single
combined Noise Texture node. The reasoning is that both nodes
intrinsically do the same thing, which is the layering of Perlin noise
derivatives to produce fractal noise. So the patch de-duplicates code
and unifies the use of fractal noise for the end use.
Since the Noise node had a Distortion input and a Color output, while
the Musgrave node did not, those are now available to the Musgrave types
as new functionalities.
The Dimension input of the Musgrave node is analogous to the Roughness
input of the Noise node, so both inputs were unified to follow the same
behavior of the Roughness input, which is arguable more intuitive to
control. Similarly, the Detail input was slightly different across both
nodes, since the Noise node evaluated one extra layer of noise. This was
also unified to follow the behavior of the Noise node.
The patch, coincidentally fixes an unreported bug causing repeated
output for certain noise types and another floating precision bug
#112180.
The versioning code implemented with this patch ensures backward
compatibility for both the Musgrave and Noise Texture nodes. When
opening older Blender files in Blender 4.1 the output of both nodes are
guaranteed to always be exactly identical to that of Blender files
created before the nodes were merged in all cases.
Forward compatibility with Blender 4.0 is implemented by #114236.
Forward compatibility with Blender 3.6 LTS is implemented by #115015.
Pull Request: #111187
Empty hair geometry in Cycles may still report having one curve, even when
there are no actual segments in that curve. This caused an attempt to build
an acceleration structure with zero primitives, which due to other setup
OptiX rejected with an error. Fix that by checking the number of segments
rather than the number of curves in the hair geometry, since the former will
always be zero for empty geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/115044
The first problem was triangles with motion blur were all grouped into
one category without separating the ones with and without triangle
motion steps.
The second problem was HIP RT uses the generic motion triangle
intersection function and this function checks prim_visibility buffer.
HIP RT doesn't provide the buffer per primitive but passes it to HIP RT
core per instance.
The buffer name was changed to prim_visibility from visibility to be
the same as what Cycles uses but when the motion triangle intersection
function is called from HIP RT kernels, the instance id is passed to
the function instead of primitive id.
Pull Request: https://projects.blender.org/blender/blender/pulls/114555
This PR works around an issue where zero-filled motion TLAS instance descriptors can cause unexpected hangs during downstream TLAS builds on M3. Instead of zeroing the descriptor we insert an explicit "null" BLAS, achieving the same result.
Pull Request: https://projects.blender.org/blender/blender/pulls/114544
Remove `Material > Shadow Mode` and use `Object > Shadow Ray Visibility`
and `Material > Transparent Shadows` instead.
The versioning system auto-updates objects/materials in EEVEE
scenes so their behavior is as close as possible to the previous one.
Update Cycles to use the native `use_transparent_shadow` property.
Note:
Material changes don't set any `recalc` flag on the objects that use
them, so the EEVEE Next shadow maps don't update when changing
settings/nodes.
Fixing this issue is required for 4.1, but it's out of the scope of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/113980
Brecht Van Lommel
Raul Fernandez
Campbell Barton
Hans Goudey
Damien Picard
Nikita Sirgienko
Attila Afra
Thomas Dinges
JonasDichelle
Sergey Sharybin
Miguel Pozo
Michael Jones
Attila Áfra
Stefan Werner
Alaska
Lukas Stockner
Xavier Hallade
Pierrick Bouvier
salipourto
Jacques Lucke
bsavery
Hoshinova
Weizhen Huang
Werner, Stefan
Jesse Yurkovich
Hans Goudey
Leon Marz
Clément Foucault
Patrick Mours