Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
AVFormatContext::duration was used without checking it was set,
calculations for the frame-rate cast -INT64_MAX to a double,
scaled it then cast to an integer - overflowing.
On my system the result was a negative number so the duration was never
usable in practice.
Add an explicit check for this so the duration is left at zero instead.
Resolve issues with corner-cases introduced by [0].
- Comparing the filename & filepath was no longer a valid way to check
for a directory component since the extension was stripped.
- Use BLI_path_extension_or_end which doesn't confuse extensions with
the dot from hidden files.
The variable name include_directory was also misleading.
[0]: 1a648f5b22
Building the depsgraph from non-main thread is unsafe currently, as it
may trigger some deferred processing on the Main data itself (here, the
update/resync of viewlayer collections).
So this commit moves the building of the export depsgraph back into the
main thread for the USD exporter, while keeping the depsgraph evaluation
code (which is typically the heavy part with complex scenes) into the
threaded job worker code.
Issue was randomly (but fairly commonly) reproducible when trying to export
most of the Pets project production files (on linux debug build with ASAN).
Root issue has been reported and is being discussed in #112534, ideally a
better solution can be designed at depsgraph level in the future.
NOTE: Should likely also be back-ported to 3.6 and 3.3 LTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/113537
Continue allowing spacebar search for all dropdown and context menus,
but also add the ability to allow some menus to have type to search,
like Add Modifiers, Objects, Nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113520
In !112591, nodes got the ability to group sockets into panels. The
labels for these sockets are automatically shortened if they begin
with the same text as their parent labels. For instance, "Transmission
Weight" will be shortened to just "Weight" because it is under the
"Transmission" panel.
While this is a good heuristic for English, it breaks down in
languages which do not have the same word order.
This commit adds a `.short_label()` callback to socket declarations so
that a shortened label can be explicitly declared.
It also adds two regexps to the translation script so that these new
fields can be extracted to the .po translation files. One extracts the
label with a translation context, the other without. Only the one
without context is currently in use.
The current automatic shortening logic is kept and will be used only
if a shortened label is not manually provided.
Fixes#112970: Node socket labels under panels are not shortened when
translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113070
Custom drop targets for views are supposed to use `DropTargetInterface` as the
base class, and view items `TreeViewItemDropTarget`. Light linking used
`TreeViewItemDropTarget` for both the view and the view item drop targets. This
is because they both used the same intermediate base class.
After suggestion from Sergey, this uses composition instead of multiple
inheritance, so `CollectionDropTarget` becomes a member instead of a base
class.
Pull Request: https://projects.blender.org/blender/blender/pulls/113550
Remove the selection attributes on the non-selected domains, since they
will be automatically filled by domain interopolation anyway. Arguably
this should be fixed in a more general way, either by ensuring they are
always on the expected domains or more gracefully handling the case
when they aren't at a lower level. But for this node, for now this is
a simpler approach.
Updated CacheReader_open_usd_object() to issue a warning and
return early if the given object path does not refer to a
valid prim on the USD stage, to avoid crashing when attempting
to create a reader from an invalid prim.
Pull Request: https://projects.blender.org/blender/blender/pulls/113524
Caused by 6a49041be3 .
Above commit checks an existing nameproperty for collection items, but
it does so in a way that it only checks the "parent" type. If these are
"subclassed" though, we might not have the nameproperty defined on the
"parent" class (but on the subclass instead).
Code would then error out with e.g. "FreestyleLineStyle.color_modifiers
does not support string lookups".
In the case of the report the following happened.
- linestyle modifiers (`LineStyleModifier`) can be any of:
-- `color_modifiers` / `LineStyleColorModifier`
-- `alpha_modifiers` / `LineStyleAlphaModifier`
-- `thickness_modifiers` / `LineStyleThicknessModifier`
-- `geometry_modifiers` / `LineStyleGeometryModifier`
But all of the above have subtypes, e.g.
`LineStyleColorModifier_AlongStroke`,
`LineStyleColorModifier_DistanceFromCamera`, ...
Currently, the `nameproperty` is not defined e.g. on the
`LineStyleColorModifier` (but instead on the subtypes).
Prior to 6a49041be3 (without
`RNA_property_collection_lookup_string_has_nameprop` in place),
`pyrna_prop_collection_subscript_str` could still actually find the
nameprop because it iterates into the collection and got it on the
actual Item (`LineStyleColorModifier_DistanceFromCamera` instead of
`LineStyleColorModifier`).
So while it might be possible to refine
`RNA_property_collection_lookup_string_has_nameprop` to descend into
subclasses (I didnt find an obvious way though other than scanning all
existing modifiers [not modifier types -- we would need a way to find
all types that inherit from e.g. `LineStyleColorModifier`] which kind of
defeats the purpose of checking this early), this PR moves the name
definition from the subclass to the parent class (so way from
`rna_def_modifier_type_common`) -- and this way,
`RNA_property_collection_lookup_string_has_nameprop` can properly pick
up the nameprop. It does a bit of code duplication though.
Pull Request: https://projects.blender.org/blender/blender/pulls/113290
The issue was that custom data layers were modified without checking
that the data was not shared. Now the data is unshared first.
I also added an assert to catches this kind of issue more directly.
Exposed by cba9f47562 (but actually caused by 4d668e6825 I think).
Because of 4d668e6825 , the `StripDrawContext` `content_start` &
`content_end` were wrong for hold still regions.
These wrong extends were then used in cba9f47562 .
Now actually update `StripDrawContext` `content_start` & `content_end`
when hold still regions are in play (instead of just calling the right
functions [but not using their return values]).
Pull Request: https://projects.blender.org/blender/blender/pulls/113494
Set the "I/O error" if the result from read is larger than the requested
size, while unlikely - set the error so an error return always sets the
`errno`.
Making some liboverride local will break/corrupt liboverride hierarchies
in many cases. So that function (or its caller, in some cases) need to
call #BKE_lib_override_library_main_hierarchy_root_ensure to re-validate
(and re-generate if needed) the liboverride hierarchy roots.
The code ensuring a valid liboverride hierarchy root ID pointer for all
liboverrides in a given Main would fail in some cases, and crash on
asserts (in Debug builds) or due to corrupted data later in code
(release builds).
The main issue fixed here is re-entry in case of dependency loops (a
same ID being checked more than once within the same chain of recursive
calls to ensure its hierarchy root is valid). Solved the usual way now,
using the intermediate 'PROCESSING' flag instead of setting immediately
the 'PROCESSED' one, when recursively processing the chain of
dependencies.
A second issue fixed in that code was that in some cases, it could leave
the invalid existing hierarchy root pointer unchanged, because it could
not find a 'valid enough' alternative.
NOTE: This data corruption is presumably caused by 'make local'
operations on liboverride hierarchy root IDs. This will be addressed as
a second commit.
For reference, issue is reproducible when opening
`/promo/splash/040_0010.lighting.splash.blend` from Pets SVN repo r3106.
Caused by 2cead79747
The clip_plane count in BLI_kdopbvh.c was incorrectly reduced.
To solve, make the size of the clip_plane array variable.
This eliminates the need to keep values in sync.
According to the documentation `read` isn't required to read all the
data requested. Although until recently I'd never encountered this and
none of Blender's code checks for read succeeding but not reading the
requested size.
Resolves#113473 where images over 2gb fail to load.
Ref !113474.
