This PR updates the VSE strip modifiers interface.
It now uses the same design as the object modifiers.
Changes:
* Except for the "Mask Input" subpanel, the modifier UIs are unchanged.
* Modifiers can now be rearranged using drag & drop.
* Additionally, there is now an active strip modifier. This is exposed
though python via `strip.modifiers.active`.
This is in part for !139634 which needs the concept of an active modifier.
Notes:
* The `modifier.cc` file included all the implementation of all modifiers.
With the addition of a another new callback in this PR, this file was
getting quite big so I split everything out into individual files for all
modifiers. The modifiers are getting registered at launch.
* The modifier panels are getting added using a UI template
(`template_strip_modifiers`) very similar to the object modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/145367
* Modify --log-level to accept error/warning/info/debug string values
* Add --log-show-source, now hidden by default
* Remove --log-show-basename, path is now on own line
* Add --log-show-memory
* Remove --log-show-timestamp, now always shown
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Add own simple logging system to replace glog, which is no longer
maintained by Google.
* When building in Blender, integrate with CLOG and print all messages
through that system instead.
* --log cycles now replaces --debug-cycles. The latter still works but
is no longer documented.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
This commit implements #125759.
It removes:
* Blender does not build on big endian systems anymore.
* Support for opening blendfiles written from a big endian system is
removed.
It keeps:
* Support to generate thumbnails from big endian blendfiles.
* BE support in `extern` or `intern` libraries, including Cycles.
* Support to open big endian versions of third party file formats:
- PLY files.
- Some image files (cineon, ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/140138
Instead of allowing leaks when parsing arguments, always cleanup before
calling exit(). This impacts -a (animation player), --help & --version
arguments, as well as scripts executed via --python which meant tests
that ran scripts could leak memory without raising an error as intended.
Avoid having suppress warnings & rationalize in code-comments when
leaking memory is/isn't acceptable, any leaks from the animation-player
are now reported as well.
This change exposed leaks: !140182, !140116.
Ref !140098
- ImBuf reference counting: turn that into just an atomic integer
- Cachefile safety: turn into a mutex, since work under the spinlock
was quite heavy (hashtable creation, other memory allocations)
- Movie clip editor: turn into a mutex, since work under the spinlock
was very heavy (reading files from disk, etc.)
- Mesh intersect: remove the previously commented out spinlock path;
replace BLI mutex with C++ mutex for shorter code
Pull Request: https://projects.blender.org/blender/blender/pulls/137989
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
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
- 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
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
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
This removes the legacy Grease Pencil modifiers from the code.
These should have already been inaccessible from the UI and hidden from
the user. The modifiers have been reimplemented for the new GPv3
data structure.
On top of the modifier code, some other related things have been
removed as well:
* Operators related to the legacy modifiers.
* Keymaps for the legacy modifier operators.
* Some bits of code that used modifier functions.
Some code has to be kept, because it is still used:
* The core line art code, which is used by the new line art modifier. It's
moved to `modifiers/lineart`.
* The DNA structs for the legacy modifiers. They are still needed for
conversion.
* A few kernel functions for the modifiers are kept (also for conversion).
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/125102
This is the first commit of the several required to support
subprocess-based parallel compilation on OpenGL.
This provides the base API and implementation, and exposes the max
subprocesses setting on the UI, but it's not used by any code yet.
More information and the rest of the code can be found in #121925.
This one includes:
- A new `GPU_shader_batch` API that allows requesting the compilation
of multiple shaders at once, allowing GPU backed to compile them in
parallel and asynchronously without blocking the Blender UI.
- A virtual `ShaderCompiler` class that backends can use to add their
own implementation.
- A `ShaderCompilerGeneric` class that implements synchronous/blocking
compilation of batches for backends that don't have their own
implementation yet.
- A `GLShaderCompiler` that supports parallel compilation using
subprocesses.
- A new `BLI_subprocess` API, including IPC (required for the
`GLShaderCompiler` implementation).
- The implementation of the subprocess program in
`GPU_compilation_subprocess`.
- A new `Max Shader Compilation Subprocesses` option in
`Preferences > System > Memory & Limits` to enable parallel shader
compilation and the max number of subprocesses to allocate (each
subprocess has a relatively high memory footprint).
Implementation Overview:
There's a single `GLShaderCompiler` shared by all OpenGL contexts.
This class stores a pool of up to `GCaps.max_parallel_compilations`
subprocesses that can be used for compilation.
Each subprocess has a shared memory pool used for sending the shader
source code from the main Blender process and for receiving the already
compiled shader binary from the subprocess. This is synchronized using
a series of shared semaphores.
The subprocesses maintain a shader cache on disk inside a
`BLENDER_SHADER_CACHE` folder at the OS temporary folder.
Shaders that fail to compile are tried to be compiled again locally for
proper error reports.
Hanged subprocesses are currently detected using a timeout of 30s.
Pull Request: https://projects.blender.org/blender/blender/pulls/122232
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
Making arguments call into Python was impractical because Python
is only initialized for ARG_PASS_FINAL.
Replace "--command" specific logic with a general method of arguments
requesting to be executed once all sub-systems have been initialized.
Without this, the `main()` function needs hard coded logic to support
any time an argument needs to use Python internally.
Add support for add-ons to define commands using the new argument
`-c` or `--command`.
Commands behave as follows:
- Passing in a command enables background mode without the need to pass
in `--background`.
- All arguments following the command are passed to the command
(without the need to use the `--` argument).
- Add-ons can define their own commands via
`bpy.utils.register_cli_command` (see examples in API docs).
- Passing in `--command help` lists all available commands.
Ref !119115
This adds an sse42 cpu check on startup for both linux and windows,
mac has been excluded, since there are no intel based macs that do
not support SSE42.
The way this works is, we count on the OS to initialize the shared
libraries in the order they are linked (which currently holds true)
before calling the initialization code in the main executable. This
allows us to check the CPU before running any of the code in the main
executable that might not be supported by the current isa.
Changing those build flags is for a future PR, but for now and for
future reference: blender_cpu_check must be build without optimized CPU
flags so it'll be able to run on older CPUs.
some code has been duplicated from blenlib, there's really no way around
that since we cannot link blenlib as it may be build with optimized cpu
flags.
Windows currently gives a popup to inform the user, while linux reports
to the console, there may be better ways to communicate with linux users
with perhaps some generic GUI popup, but I'm unaware of these and will
leave this for the linux platform maintainer to polish.
Part of #116592
Pull Request: https://projects.blender.org/blender/blender/pulls/118054
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
This reverts #110582 - the workaround is no longer needed, as MS have updated
the version of mesa they ship as part of their compatibility pack, which contains
a workaround on that side instead.
This means that the supported version of OpenGL based on the host GPU is now
correct, bar `GL_ARB_texture_view`.
`GL_ARB_texture_view` is faked for ARM64 devices, as the part that is not
implemented (channel casting) is not used in blender.
This means that ARM64 devices (at least) now report compatibility up to OpenGL
4.6 in the system info export.
See: 698344b93c
Pull Request: https://projects.blender.org/blender/blender/pulls/116052
