Regression in [0] which incorrectly swapped the check for the
`use_scripts` property being set with the value it was set to.
Resolve this error as well as the "Recover Last" operator
which never worked.
[0]: 8c688a052c
When building an ASAN build, I get this link error currently:
```
ld.lld: error: version script assignment of 'global' to symbol '__progname' failed: symbol not defined
ld.lld: error: version script assignment of 'global' to symbol 'environ' failed: symbol not defined
```
The solution (as proposed by Brecht) is to change the symbol names into patterns with a wildcard.
That way the linker does not fail when the symbols are not found.
Pull Request: https://projects.blender.org/blender/blender/pulls/137153
Implements a crash dialog for Windows.
The crash popup provides the following actions:
- Restart: reopen Blender from the last saved or auto-saved time
- Report a Bug: forward to Blender bug tracker
- View Crash Log: open the .txt file with the crash log
- Close: Closes without any further action
Pull Request: https://projects.blender.org/blender/blender/pulls/129974
It's better for performance to use a single thread pool for all areas of
Blender, and this gets us closer to that.
Bullet, Quadriflow, Mantaflow and Ceres still contain OpenMP code, but it
was already disabled.
On macOS, our OpenMP libraries are no longer compatible with the latest
Xcode 16.3. By removing OpenMP we no longer have to solve that problem.
OpenMP was disabled for bpy module builds on Windows ARM64, which also no
longer needs to be solved.
Pull Request: https://projects.blender.org/blender/blender/pulls/136865
python3.dll was installed for blender, but not next to the
python binary, leading to issues with subprocesses. Given
it's only a small dll the duplication isn't that big of a deal.
The issue is caused by the fact that when both compositors are used,
`fftwf_plan_dft_r2c_2d` can end up being called in parallel, which is
only thread-safe if `fftwf_make_planner_thread_safe` is called before.
This is done by `fftw::initialize_float`, but only if the FFTW threading
support library is available. Said library was not detected correctly on
Windows because of a typo, which this change addresses. This should also
make the fog glow faster on Windows because it'll now use multithreaded
FFT as intended.
This change also moves the call to `initialize_float` to the main
function because the FFTW functions it calls are not thread-safe and
because FFTW is also used by Audaspace, which cannot call it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136557
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
`MEM_[cm]allocN<T>` templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use `MEM_new` (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135620
Add a `--profile-gpu` launch argument.
When set, it generates a profile in the Trace Event Format with CPU and
GPU metrics based on GPU debug scopes.
https://profilerpedia.markhansen.co.nz/formats/trace-event-format/
The profiles are best viewed at https://ui.perfetto.dev/
Notes:
- The profiler captures everything form app start to exit.
- Being JSON based the profiles can become relatively large, but they
compress very well.
- Only OpenGL profiling is supported for now, but the report formatting
code can be shared across backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/133557
Also correct argument handling when Python arguments were passed in,
which were attempting to handle the following parameters as arguments
instead of skipping them.
* Ensure valid bit depth is set along with file type
* Guard against invalid inputs in stereo imbuf creation
* Remove some unused code
Thanks Yiming Wu for finding the cause.
Pull Request: https://projects.blender.org/blender/blender/pulls/133499
Support thumbnail that shows the file contents instead
of the default blend file icon for all files in Finder.
Some files may still have the usual blender icon as thumbnail
depending on their contents.
blender-thumbnailer process is kept alive by the system
in the background and is invoked by QuickLook when needed.
The checkbox to disable the extension is present in
the Settings app.
It will NOT be an interactive "Preview" that allows richer
interactions like Panning viewport, or rotating 3D objects.
When calling bpy.utils.expose_bundled_modules(), these modules are
added to sys.path.
This provides a solution/workaround to two problems:
* Using bpy together with packages like usd-core is problematic. Besides
crashing due to C++ symbol conflicts, it's just impossible to import
different versions of the same module, or to have distinct environment
variables for both. (#127132)
* Blender add-ons using these VFX modules do not currently work with
the bpy module.
This adds about 15MB to the bpy package.
Pull Request: https://projects.blender.org/blender/blender/pulls/133082
* BLENDER_SYSTEM_SCRIPTS support for multiple script paths, separated by
; on Windows and : on other platforms.
* New BLENDER_CUSTOM_SPLASH to replace the splash screen image.
* New BLENDER_CUSTOM_SPLASH_BANNER to overlay an image on the splash.
Contributed by Sony Interactive Entertainment: https://github.com/PlayStation-OpenSource
Only enable by default dynamic rendering local read on Qualcomm devices. NVIDIA, AMD and Intel
performance is better when disabled (20%). On Qualcomm devices the improvement can be
substantial (16% on shader_balls.blend).
`--debug-gpu-vulkan-local-read` can be used to use dynamic rendering local read on any
supported platform.
Future: Check if bottleneck is during command building. If so we could fine-tune this after the
device command building landed (#T132682).
Pull Request: https://projects.blender.org/blender/blender/pulls/132981
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Not entirely straightforward, some manual edits were done since when
this library was created, some of the work was already done.
- Remove any bf_imbuf_movie paths from INC
- Add a dependency though LIB when missing
- Add public dependency to bf_imbuf in bf_imbuf_movie since it uses the
imbuf headers in its public headers.
- Fix namespace not to have underscores
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/132407
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
The new --disable-liboverride-auto-resync commandline option will prevent
running liboverride auto-resync immediately after loading a blendfile.
This is an alternative way to setting the User Preferences Debug option
`No Override Auto Resync`.
-------
Some quick performances tests:
Loading a Gold production file goes from 26.5s to 25.9s.
Combined with the recent `--disable-depsgraph-on-file-load` option, it
goes from 3.5s to 2.9s, so another nice extra 15% speedup when only
bare-metal blendfile loading is needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132017
The new `--disable-depsgraph-on-file-load` commandline option, when used
together with the `--background` or `--command` ones, will prevent
building a depsgraph immediately after loading a blendfile.
The goal is to improve performances of batch-processing of blendfiles by
python scripts. It is intended to become the default behavior in Blender
5.0.
Scripts requiring evaluated data then need to explicitly ensure that
an evaluated depsgraph is available (e.g. by calling
`depsgraph = context.evaluated_depsgraph_get()`).
------
This disables the call to `wm_event_do_depsgraph` in `wm_file_read_post`.
Some quick performances tests:
* The whole `blendfile_versioning` tests gain about 2% speedup. These are
almost always small and simple blendfiles.
* Loading a Gold production file however goes from 26.5s to 3.5s (almost
90% faster) when this new option is specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/131978
This changes the location of the Draco library installation path.
The new location is at the root of addons_core/io_scene_gltf2 addon, as the library is created for this addon only.
This will solve issues where the gltf addon couldn't find the library in case of global python installation or custom script/lib paths
Pull Request: https://projects.blender.org/blender/blender/pulls/131080
This is to make sure duplicate libomp/libiomp5 runtime conflicts are
detected as soon as a second runtime is initialized. Otherwise, it may
not crash until Blender's OpenMP runtime is initialized by a feature
that uses it, making such issues possibly go unnoticed. Such a conflict
can happen when an add-on has a native module that uses OpenMP and links
to a different libomp runtime, as was the case in #125255.
Currently Blender only ships with libomp on MacOS.
---
When libomp detects such an issue it should abort and print the following message:
```
OMP: Error #15: Initializing libomp.a, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/130407
CMake 3.31+ have begun emitting warnings when you feed install()
paths that are not normalized (ie have, '.' or '..' in them) easiest
fix is just not use them.
This cleans up the windows sections of the build system, the other
platform devs will have to take a look on their respective platforms.
