When adding strips that generate image on their own, while 3 or more
strips are selected, it emits error. This was caused by incorrect
handling of this case in `seq_effect_find_selected()`. If effect has no
inputs, function should return early.
Pull Request: https://projects.blender.org/blender/blender/pulls/118866
Ultimately this was due to missing nullptr check before trying to
process the image, but this should have been caught when loading
ImBufAnims. If any is missing, cancel multiview loading and load
movie as if it was single view only.
Second issue reported in the comment was caused by some shapekeys
flagged as embedded liboverride data, when their owner ID (Mesh e.g.)
is not a liboverride at all.
The `BKE_lib_override_library_validate` called on file read was only
covering real liboverride IDs, which where then supposed to take care of
their own embedded data. But since the owner ID is already a full
non-override ID, its embedded data ended up never being properly
sanitized.
Most likely more corruption data from quite old files and/or deprecated
experimental features.
For various reasons, node tools don't support some data. Shape keys aren't
supported because their format is entirely different for evaluated and
original data-blocks, and node tools currently work in the "evaluated"
world. Though that would be nice to change, in the meantime users
should at least be warned when this happens.
This PR adds a simple "Mesh shape key data removed" operator warning.
See #113662
Pull Request: https://projects.blender.org/blender/blender/pulls/118986
This fixes#116096 and is based on #115249 with some changes.
This patch contains three changes:
* `NodeSocket.links` in the Python API gives the links in the correct order.
* `NodeLink.multi_input_sort_id` gives read-only access to an id that's used
for sorting. Note that for historical reasons the highest id is the first link.
* `NodeLink.swap_multi_input_sort_id(other_link)` provides a safe way to
change the order of links connected to a multi-input socket.
Co-authored-by: Adrian Bibby Walther <adrianbibbywalther@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118987
Add label to the sculpt symmetrize options.
With no label user may confuse if other symmetry options
above are related to the symmetrize operation.
Also reorder them so the actual operation button to go bottom.
Pull Request: https://projects.blender.org/blender/blender/pulls/112915
Building the depsgraph from a worker thread is unsafe currently, as it
may trigger some deferred processing on the Main data itself.
Mimic what was already done for USD (from `5cf3654d9d`) and build the
graph before launching `export_startjob`.
Pull Request: https://projects.blender.org/blender/blender/pulls/118974
This PR extracts the common sculpt gesture code from paint_mask.cc into
a separate file in preparation for further changes to use it within the
existing `PAINT_OT_hide_show` box gesture operator and later for adding
a new *Lasso Hide* operator for #80390
Pull Request: https://projects.blender.org/blender/blender/pulls/118881
This PR initializes all brushes with the default automasking cavity
curve when a `startup.blend` file is loaded. Because there exists a
series of brushes that are added if they are not found in the
`startup.blend` file (e.g. "Paint") **after** the file is already
loaded, the existing fallback code to handle `nullptr` in the loader
code does not run.
Pull Request: https://projects.blender.org/blender/blender/pulls/118943
Over the last couple years (!) UI buttons have moved to derived classes,
meaning we don't need to use the same "a1" and "a2" variables to store
different information. At this point, that information is set specifically
by internal UI code, or functions like `UI_but_*_set`.
These values are only set to their default 0 values now (or -1 in some
non-meaningful cases). This commit removes the values from buttons
and removes the remaining a1 and a2 arguments from the UI API.
Previously these used a special "menu func" that used an argument value
passed through each menu button's a2 value. This was more complex than
necessary given the existence of generic button callbacks.
So use std::function in these remaining cases, and remove the now-unused
`butm_func` and `butm_func_arg` values in the uiBlock.
Recurse selection was not restricted to "mouse over icon" during range
selection (i.e. if we shift- double click on any area of tree element,
resurse select is still executed, which is wrong)
Also did a bit cleanup to use existing `is_over_icon` instead of calling
`outliner_item_is_co_over_icon` multiple times
Pull Request: https://projects.blender.org/blender/blender/pulls/118556
The `RNA_property_animateable` would check for some conditions, where it
is not valid to add or edit animations (e.g. if using a linked Action
ID...).
Add a new `RNA_property_drivable`, which is essentially a call to
`RNA_property_animateable` with extra checks in liboverride cases, as
drivers are stored directly in the AnimData struct, instead of their own
dedicated ID.
Pull Request: https://projects.blender.org/blender/blender/pulls/118809
The line separator needs to know vertical or horizontal orientation
at draw time, and is independent of button rect. This PR removes the
use of uiBut->a1 for this in favor of a derived struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/118969
There seems to not be a strict rule to only have armatures as parents to
single bones, apparently collada files can also be set up to have mesh
parents for bones. As a consequence, the collada importer
`joint_parent_map` is not safe to fetch objects from and assume their
data can be cast to `bArmature`.
Ultimately, the `joint_parent_map` needs to be looked at again, this
patch just avoids a crash in this scenario (so no such joints will be
iported). Still better than crashing I guess.
Pull Request: https://projects.blender.org/blender/blender/pulls/118751
No functional changes.
This PR replaces the uses of the C-style `BLI_BITMAP`
with `blender::BitVector` in `keyframing.cc`.
Note that in `BKE_animsys_nla_remap_keyframe_values` I had to
add code that maps from one to the other because I don't feel
comfortable ripping out the `BLI_BITMAP` from
`NlaEvalChannelSnapshot->remap_domain`
Pull Request: https://projects.blender.org/blender/blender/pulls/118957
This required to apply a small fix in the Metal texture uploader.
Without synchronization pixels of a wrong pass can be uploaded to
a wrong texture. This is because this code path is heavily reusing
temporary allocations, and at some point the allocation is not
considered as still in use, unless the command buffer used by the
texture uploader is submitted.
Ref #118919
Pull Request: https://projects.blender.org/blender/blender/pulls/118920
No functional changes.
This PR just replaces the `KEYFRAME_OK_CHECKS` macro with a function
`keyframe_ok_checks`.
The motivation for this is to remove the confusing use of nested macros.
Since the actual check has to be passed in, this new function takes a function as an argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/118914
One of the consequences of the mistake in 3fcf535d2e (fixed in previous
commit), was that the more recent `LIB_EMBEDDED_DATA_LIB_OVERRIDE` ID
flag could be wrongly set in some nodetrees from pre-2.76 blendfiles.
This commit adds a check that embedded IDs flagged with
`LIB_EMBEDDED_DATA_LIB_OVERRIDE` are actually embedded IDs of a
liboverride.
Pull Request: https://projects.blender.org/blender/blender/pulls/118921
In 3fcf535d2e, the `ID.flag` data was split, keeping persisten flags in
`ID.flag`, and moving runtime ones into a new `ID.tag` data.
Some versionning code was then added to cleanup the existing `ID.flag`
on file read, but embedded IDs (root node trees only, back then) are not
stored in Main data-base, and were skipped.
Note that this fixes the conversion of older (2.76.4 and older) files.
There is no reliable way to cleanup files opened and saved from more
recent versions of Blender unfortunately.
Blender crashes when using the compositor debugger. That's because it
assumes the names of the operation classes will be demangled and will
proceed to slice them causing crashes. The standard makes no guarantees
about the form of the returned type_info::name, and it is implementation
defined.
While it is possible to demangle those names and return something that
is more human readable, it doesn't seem worth it as this is only used by
developers who should have no problem identifying mangled names. So we
just display the name as is.
Pull Request: https://projects.blender.org/blender/blender/pulls/118904
Richard Antalik