Add sound pitch correction functionality, so that retimed sound strips
can preserve their original pitch.
This has been implemented as a GSoC 2025 project. Actual pitch
correction is done with Rubberband library, which has been already
included into Blender 5.0 library builds; and then most of the other
code has been in Audaspace, which was already updated within Blender
tree earlier.
So this PR just flips on Rubberband build option, and adds the
checkbox to VSE sound strips for pitch correction (on by default for
newly created sound strips). Pitch correction works with both
simple whole-strip retiming, as well as more complex retiming setups
where different parts of the strip use different speeds.
Co-authored-by: Aras Pranckevicius <aras@nesnausk.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/143347
Due to this bug only the first item in the current PATH on the system
is used when running Blender.
The PATH is appended to a string type variable, which is then used as
one element of a list in build_files\cmake\testing.cmake line 24. Since
in cmake the semicolon is a list element delimiter, we need to escape
all the semicolons in our PATH string if we want to use the variable as
a single entry in the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/146770
This is the first step of moving the create infos
back inside shader sources.
All info files are now treated as source files.
However, they are not considered in the include tree
yet. This will come in another following PR.
Each shader source file now generate a `.info` file
containing only the create info declarations.
This renames all info files so that they do not
conflict with their previous versions that were
copied (non-generated).
Pull Request: https://projects.blender.org/blender/blender/pulls/146676
This option has been removed in vs2026 and will cause a build error,
disabling this option results in our default /DEBUG being used
which is equivalent to /debug:full which is the suggested
replacement
Blender had some support for using MoltenVK. However there are some key
issues why MotlenVK cannot be used. Bugs have been reported up-stream.
As it doesn't work and holds back regular developments it will be removed
from the main branch.
Any efforts on making Vulkan run on Apple (including KosmicKrisp)
is considered a community effort and can be done in a development
branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/144602
This follows the other CMake "modernization" commits, this time for
`bf_intern_openvdb` and the OpenVDB dependency itself.
The difference with this one is that `intern/openvdb` becomes an
"optional" dependency itself. This is because downstream consumers often
want to include this dependency rather than openvdb directly, so this
target must also be optional. Optional, in this case, means the target
always exists but may be entirely empty.
Summary
- If you are using BKE APIs to access openvdb features, then use the
`bf::blenkernel` target
- If you are only using `intern/openvdb` APIs then use the
`bf::intern::optional::openvdb` target (rare)
- For all other cases, use the `bf::dependencies::optional::openvdb`
target (rare)
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/137071
Add a [Python code generator][1] that takes an OpenAPI definition and
outputs the corresponding data model as [dataclasses][2]
This is intended to be used in the Remote Asset Library project, to
create, download, parse, and validate information of a remote asset
library.
[1]: https://koxudaxi.github.io/datamodel-code-generator/
[2]: https://docs.python.org/3/library/dataclasses.html
## Running the Generator
The generator is a Python script, which creates its own Python
virtualenv, installs the dependencies it needs, and then runs the
generator within that virtualenv.
The script is intended to run via the `generate_datamodels` CMake
target. For example, `ninja generate_datamodels` in the build
directory.
## Details
The virtualenv is created in Blender's build directory, and is not
cleaned up after running. This means that subsequent runs will just
use it directly, instead of reinstalling dependencies on every run.
## Generated Code & Interaction with Build System
It is my intention that the code generation _only_ happens when the
OpenAPI specification changes. This means that the generated code will
be committed to Git like any hand-written code. Building Blender will
therefore _not_ require the code generator to run. Only people working
on the area that uses the generated code will have to deal with this.
Pull Request: https://projects.blender.org/blender/blender/pulls/139495
This moves the logic to create the parent folder to data_to_c itself
rather than having cmake do it, preventing several thousand cmake instances
to be started.
see pr#141404 for details/benchmarks
Pull Request: https://projects.blender.org/blender/blender/pulls/141404
This requires a minimum driver version of 535, however most devices
were already requiring 570 due to the CUDA toolkit version.
The update is required to be able to use an API function for correct
stack size calculation.
Code for older API versions has been removed.
Fix#138185: OSL custom camera errors with OptiX
Pull Request: https://projects.blender.org/blender/blender/pulls/139801
Almost all content in the libdir we can regenerate, wintab however
is not one of them, and if you generate a new lib folder it's one
of the things you have to manually copy back into place.
this PR moves it out of the libdir and into /extern
Pull Request: https://projects.blender.org/blender/blender/pulls/128873
Some Linux multi lib setups have a helper include file for Jemalloc that
in turn includes the actual header file. This makes our version regex fail.
As the Jemalloc version we are checking for is no longer in any of
the currently supported LTS linux distros, we can safely drop it.
Pull Request: https://projects.blender.org/blender/blender/pulls/139225
OpenColorIO is now a dynamic library, and these are included in it. The
legacy code for the static library case was causing the Homebrew libraries
to be found and linked to.
Pull Request: https://projects.blender.org/blender/blender/pulls/139087
Pretty bare bones but gets the job done, unlike the gcc
tooling, this will work for release builds, the performance cost
of it is on the high side of things, the full test suite tests take over
an hour for me with code coverage support enabled on a release build.
I have not timed a debug build. Given developers can just run their
tests to get coverage data over what they are working on, I feel this
is still useful tooling to have.
This adds the 3 targets for clang and adds a single gcc target
coverage-reset - this removes the collected code coverage data and
report
coverage-report - This merges the collected data and generates the
report (new for gcc)
coverage-show - This merges the collected data and generates the report
and opens it in the browser
This relies on llvm-cov and llvm-profdata being available if not found
code coverage is disabled.
Note: A full test run requires an obscene amount of disk space, a
complete test run takes about 125GB and takes 12 minutes to merge, so
provision the COMPILER_CODE_COVERAGE_DATA_DIR folder accordingly
Example report in PR
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
While shaderc is a c++ library that normally requires debug libs
for ABI reasons, shaderc only exports a C interface, so it will
link release mode libs just fine even for debug builds.
This drops the time required for GPU_shader_compile_static in a
debug build from 5 mins to 3 sec for @pragma37
no changes for release configurations.
This change moves the tests data files and publish folder of assets
repository to the main blender.git repository as LFS files.
The goal of this change is to eliminate toil of modifying tests,
cherry-picking changes to LFS branches, adding tests as part of a
PR which brings new features or fixes.
More detailed explanation and conversation can be found in the
design task.
Ref #137215
Pull Request: https://projects.blender.org/blender/blender/pulls/137219
Enable optimizations on Debug builds for executables used for the build
process (datatoc and glsl_preprocess) and enable unity builds for
shader preprocessing targets.
Debug: From 28.9s to 5.7s
Release: From 4.9s to 3.5s
Pull Request: https://projects.blender.org/blender/blender/pulls/138274
See #129009 for context.
The preprocessor parses metadata and writes a header file containing
an inline function that inits the `GPUSource` with the metadata.
These header files are then included inside `gpu_shader_dependency.cc`.
This still keep the usage of the `metadata` enums and classes to avoid
pulling the whole blender module inside the preprocessor executable.
This speeds-up startup time in Debug build:
`gpu_shader_dependency_init`
- Before : 37ms
- After : 4ms
I didn't measure release, but it is unlikely to be noticeable (in the
order of 4ms > 1ms).
Pull Request: https://projects.blender.org/blender/blender/pulls/138070
Adds the 'manifold' solver option to the Boolean geo node and to
the Boolean modifier. This solver is about as fast, or faster,
than the current float solver, and is robust against floating
point issues like the Exact solver. But currently it only
works on mesh arguments that are strictly manifold.
See https://projects.blender.org/blender/blender/issues/120182
for many more details.
This patch changes the default macOS x64 linker from the slower legacy
"classic" linker, to the much faster default modern macOS linker. A new
CMake option `WITH_LEGACY_MACOS_X64_LINKER` was also introduced to use
the old linker, set to OFF by default.
As an example from testing on an Intel Macbook, this makes linking time
go from 3min25s to 10s after this change. The reason why the legacy
linker was enforced on x64 in the first place was to silence "platform
load command not found" warnings during linking. Since this behavior is
still desired on the BuildBot, the `WITH_LEGACY_MACOS_X64_LINKER` option
is enforced in the BuildBot macOS configs.
Pull Request: https://projects.blender.org/blender/blender/pulls/134639
Adds a C++ based FBX importer, using 3rd party ufbx library (design task:
#131304). The old Python based importer is still there; the new one is marked
as "(experimental)" in the menu item. Drag-and-drop uses the old Python
importer; the new one is only in the menu item.
The new importer is generally 2x-5x faster than the old one, and often uses
less memory too. There's potential to make it several times faster still.
- ASCII FBX files are supported now
- Binary FBX files older than 7.1 (SDK 2012) version are supported now
- Better handling of "geometric transform" (common in 3dsmax), manifesting
as wrong rotation for some objects when in a hierarchy (e.g. #131172)
- Some FBX files that the old importer was failing to read are supported now
(e.g. cases 47344, 134983)
- Materials import more shader parameters (IOR, diffuse roughness,
anisotropy, subsurface, transmission, coat, sheen, thin film) and shader
models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better)
- Importer now creates layered/slotted animation actions. Each "take" inside
FBX file creates one action, and animated object within it gets a slot.
- Materials that use the same texture several times no longer create
duplicate images; the same image is used
- Material diffuse color animations were imported, but they only animated
the viewport color. Now they also animate the nodetree base color too.
- "Ignore Leaf Bones" option no longer ignores leaf bones that are actually
skinned to some parts of the mesh.
- Previous importer was creating orphan invisible Camera data objects for
some files (mostly from MotionBuilder?), new one properly creates these
cameras.
Import settings that existed in Python importer, but are NOT DONE in the new
one (mostly because not sure if they are useful, and no one asked for them
from feedback yet):
- Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX
file itself specifies the axes fairly clearly. USD/glTF/Alembic also do
not have settings to override them.
- Use Pre/Post Rotation (defaults on): feels like it should just always be
on. ufbx handles that internally.
- Apply Transform (defaults off, warning icon): not sure if needed at all.
- Decal Offset: Cycles specific. None of other importers have it.
- Automatic Bone Orientation (defaults off): feels like current behavior
(either on or off) often produces "nonsensical bones" where bone direction
does not go towards the children with either setting. There are discussions
within I/O and Animation modules about different ways of bone
visualizations and/or different bone length axes, that would solve this
in general.
- Force Connect Children (defaults off): not sure when that would be useful.
On several animated armatures I tried, it turns armature animation
into garbage.
- Primary/Secondary Bone Axis: again not sure when would be useful.
Importer UI screenshots, performance benchmark details and TODOs for later
work are in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/132406
This was introduced during EEVEE-next developement
cycle to not make the buildbot fail because of EEVEE
render tests.
These have stabilized now and we can remove this option.
Pull Request: https://projects.blender.org/blender/blender/pulls/137545
This patch replaces our own FindTBB module with TBB's own TBBConfig
module. On the technical side of things, this harvests the TBB CMake
config modules, and switches our TBB CMake find_package calls from
Module mode to Config mode. Integration was done using OpenPGL as a
blueprint for parsing TBB target's property back into CMake variables
(TBB_LIBRARIES and TBB_INCLUDE_DIRS).
Pull Request: https://projects.blender.org/blender/blender/pulls/137063
Removes '/' prefix from gtest filter for parameterized tests. This prefix
was causing tests in fixtures like VKRenderGraphTestScheduler and
VKRenderGraphTestRender to be skipped in `make test`.
Only parameterized tests with an InstantiationName will have a '*/' in
their names as part of a prefix. But according to the spec, InstantiationName
is optional, and if not set it wont generate prefixes. In these cases, the
gtest_filter produced will not match the test names, and cause `make test`
to not run the tests.
Removing this '*/' prefix should still match any tests with a non-empty
InstantiationName.
Pull Request: https://projects.blender.org/blender/blender/pulls/136987
