This replaces the usage of the old `BKE_blendfile_write_partial` API by
the new `PartialWriteContext` class, in the code generating the 'copy
buffer' blendfile used for copy-pasting video sequences.
This is an interesting example of advanced/complex ID dependencies
handling with the new `PartialWriteContext`, as the 'main. scene storing
VSE data needs to be created (instead of copying the existing scene),
and then the ID dependencies of its sequences need to be filtered based
on their types.
There is no behavioral changes expected here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Pull Request: https://projects.blender.org/blender/blender/pulls/123993
This makes code behind the `bpy.data.libraries.write()` API use the new
`PartialWriteContext` class, instead of the old
`BKE_blendfile_write_partial` API.
NOTE: This also means that the `blendfile_io` tests using this python
API are now using the new class.
No behavioral changes are expected here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This commit introduces a new `PartialWriteContext` class, which wraps
around a regular Main struct. It is designed to make writing a set of
IDs easy and safe, and to prepare for future 'asset library editing'
low-level code.
The main goal of this refactor is to provide the same functionalities
(or better ones) than existing partial write code, without the very
bad hacks currently done.
It will replace within the coming weeks all current usages of the
`BKE_blendfile_write_partial` API.
Essentially, it allows to:
* Add (aka copy) IDs from the G_MAIN to the partial write context.
* This process handles dependencies and libraries automatically.
* A refined handling of dependencies is possible through an optional
'filtering' callback.
* Keep track of added IDs, to allow de-duplication in case data is added
more than once.
* Cleanup the context (i.e. remove unused IDs).
* Write the context to disk as a blendfile.
Since the context keeps information to find matches between its content
and IDs from the G_MAIN, its lifespan is expected to be _very_ short.
Otherwise, changes in G_MAIN (relationships between IDs, their session uid,
etc.) cannot be tracked by the context, leading to inconsistencies.
A partial write context should typically be created, filled, written and
deleted within a same function.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Also make ID pointer parameter passed to `BKE_main_idmap_remove_id`
const.
There is no behavioral changes expected from that commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This commit allows to initialize and clear a Main struct which
allocation is handled separately.
There is no behavioral change expected from this commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
The new `LIB_ID_MAKELOCAL_INDIRECT` option will force indirectly linked
data to also be made local. Note that this was already the case when a
whole library was made local.
Also some cleanup of options for 'make local', and pass
`IDWALK_IGNORE_MISSING_OWNER_ID` to the ID copying code for ID
management, since typically the owner pointer of embedded IDs at that
point is not yet set to its valid value.
There is no behavioral changes expected from this commit (even though
technically it does affect existing ID copying's behavior, there should
be no change in practice).
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This was caused by the light culling system not
allocating enough tiles to cover the sphere lightprobe
render target.
Taking the max size between the lightprobe target and
the film fixes the issue.
Fixes#117444
Part of #118145.
Duplicate the function three times so it can be implemented specifically
for each data structure. The duplication can be reduced in the future by
using the same methods as the sculpt brush refactor.
This also fixes the incorrect usage of `PBVH_ITER_ALL`, which doesn't
just also iterate over hidden vertices like was probably intended, but also
processes vertices shared between different PBVH nodes multiple times,
one for each node they're contained in.
The function direction_to_fisheye_lens_polynomial computes the inverse of
fisheye_lens_polynomial_to_direction.
Previously the function worked almost correctly if all parameters except k_0
and k_1 were zero (in that case it was correct except for flipping the x-axis).
I replaced the fixed-point iteration (?) by Newton's method and implemented a
test to make sure it works correctly with a wider range of parameter sets.
Pull Request: https://projects.blender.org/blender/blender/pulls/123737
Blender doesn't render the scene even though a Cryptomatte node exists.
That's because Blender only considers Render Layer nodes, but
Cryptomatte node can reference scenes as well. This patch fixes that by
putting Cryptomatte nodes into consideration.
Pull Request: https://projects.blender.org/blender/blender/pulls/123814
The 'Filter' F-Curve modifier type was never actually implemented, so
it's now properly removed from the code.
The enum entry `FMODIFIER_TYPE_FILTER` in `DNA_anim_types.h` is kept, so
that it's clear that this once existed (which explains what would
otherwise be a hole in the values of the enum entries).
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Avoid looping over all F-Curves in `bke::action_foreach_id()`. This was
only necessary to support the possible ID* in custom properties on the
Python F-Curve modifier, but that modifier has been removed in the
preceeding commit.
Even though `BKE_fcurve_foreach_id()` exists, it is only relevant for
drivers, but the F-Curves stored in an Action are always just animation
data, not drivers.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Remove all traces in the source code of the never-properly-implemented
'Python' F-Curve modifier type. It was introduced in 44e5b7788b.
This modifier was never coded to completion, couldn't be created, didn't
have a GUI, and probably would have caused severe performance issues if
it were ever implemented.
Not only that, but the modifier had space for custom properties
(IDProperties), which means that it could point to any ID. This in turn
means that `bke::action_foreach_id()` would have to loop over every
F-Curve and every F-Curve modifier to handle such relations. By removing
this modifier type, that loop can also be removed from that function.
Note that F-Curves can only refer to other IDs when they are used as a
driver. However, the F-Curves stored in an Action as animation data are
never drivers.
`BKE_fcurve_foreach_id()` is now only relevant when the F-Curve is a
driver, which I've added to its documentation.
The enum entry `FMODIFIER_TYPE_FILTER` in `DNA_anim_types.h` is kept, so
that it's clear that this once existed (which explains what would
otherwise be a hole in the values of the enum entries).
No functional changes should be observable by Blender users, as this
feature doesn't seem to have ever existed in a way that could be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Instead of using hard-coded array indices that happen to match the
`FMODIFIER_TYPE_...` enum values, actually use the enum items.
Also add some assertions that those indices actually match the type
numbers declared by the `FModifierTypeInfo` structs.
To avoid rewrapping long lines, remove comments that basically repeat
the code anyway.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Currently, the Render mode of the GPU Cryptomatte mode extracts the
Cryptomatte layers based on information in the RenderResult of the
scene. This means the node will not work if no RenderResult exists,
which is typically the case for the viewport compositor, and especially
after #123378.
To fix this, we simply acquire the passes directly from the appropriate
view layer based on the node's layer name. The render compositor context
implementation will handle the extraction from the RenderResult, while
the viewport compositor will just return the DRW passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123817
Extensions with a manifest that can't be parsed caused can exception
in the add-ons UI.
Account for errors loading the manifest, falling back to dummy values
& show a warning that the exceptions manifest could not be parsed.
