The issue here is that the `parent` pointer of indirectly linked
libraries would not be propoerly cleared when their current parent was
deleted.
Note that this fix will leave effectively indirectly linked libraries
shown as directly used ones in the UI, until the blendfile is saved and
reloaded. This is not a new issue though, deleting a parent library in
the Outliner has the same effect.
Fairly straightforward.
Note that only the Noise modifier is handled in this commit, for demonstration/testing purposes.
The other modifiers remain TODO and will be handled in later commits.
Pull Request: https://projects.blender.org/blender/blender/pulls/118415
This is generally more flexible and less error prone. The struct
implements a proper descructorfor this anyway. That also makes the
separate free function unnecessary-- it's redundant with the destructor.
This converts the "Layer Adjustments" from GPv2 into modifier setups in GPv3.
They include:
* Layer tint
* Layer thickness offset
* Thickness factor (for the entire object)
Both the "layer tint" and the "thickness factor" are converted using the existing modifiers.
Because the thickness modifier uses a factor instead of an offset, the "layer thickness offset" is converted to a geometry nodes modifier setup for each layer that adds an offset value to the radii instead of multiplying by a factor.
Pull Request: https://projects.blender.org/blender/blender/pulls/118149
In GPv2, strokes could be edited using bézier curve handles. This was implemented by creating an `editcurve` for a stroke that would store the handles and other attributes.
In GPv3, we can directly make use of the `CURVE_TYPE_BEZIER` and store the curve as a bézier curve.
Note: This PR only handles conversion. Not rendering or anything else.
Pull Request: https://projects.blender.org/blender/blender/pulls/118386
Essentially move the Object-handling logic also into
`bke::greasepencil::convert::`. This code will also be needed for
automatic conversion on fileread etc.
It also helps to keep all the conversion logic in one place (especially
since there is going to be way more done at object level - modifiers,
animation, etc.).
Pull Request: https://projects.blender.org/blender/blender/pulls/118384
This reverts commit 31b8323b93.
Allocating memory in parallel is fine as long as each threads only
writes to the memory it allocates, which is the case here.
`BKE_lib_override_library_validate` used on fileread to ensure all
liboverrides are valid was using direct call to
`BKE_lib_override_library_free`. However, this was lacking the handling
of embedded dependencies (from liboverride PoV), in particular
ShapeKeys.
Since these shapekeys were still tagged as embedded liboverrides,
liboverride code would later assume their owner (mesh etc.) was also a
valid liboverride, leading to various potential issues.
Use instead `BKE_lib_override_library_make_local`, which also ensures
that embedded dependencies are handled properly.
This adds group ids to the `Sample Nearest Surface` node. This allows e.g. finding
the closest point on a specific mesh island.
Three new sockets are added:
* `Group ID`: Is evaluated on the face domain and splits the input mesh into multiple
parts, each with its own id.
* `Sample Group ID`: Determines in which group the closest nearest surface is detected.
* `Is Valid`: Outputs true if a nearest surface was found, it's false if the group is empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/118150
Use IDTypeInfo data as much as possible, to avoid too many functions
`switch`ing over all ID type values.
Now only `BKE_idtype_idcode_to_index` and `BKE_idtype_idfilter_to_index`
do that, all others are using one of the above to retrieve the valid
IDTypeInfo and return data from it.
Also tweaked some namings to make them more consistent.
No behavioral changes expected here.
This data was 'hidden' away in a util in
`lib_query.cc`, which made it hard to discover and keep up-to-date.
However, as shown by e.g. #108407, critical low-level features in ID
management code, such as remapping, now rely on this information being
valid.
Also simplify `BKE_library_id_can_use_filter_id` and
`BKE_library_id_can_use_idtype` to make them more generic, relying on
IDTypeInfo to retrieve IDtype-specific info.
No behavioral changes expected here.
Own d38824bc02 mistakenly added the 'FILTER_ID_KE' to the list IDTypes
usable by Lights (`ID_LA`) instead of Lattices (`ID_LT`)...
Note that this did not cause any additional issue, but only missed part
of the expected fix.
These reports were embedded in the window manager DNA,
but they were always cleared when reading it from files. It's clearer
to just not store the reports in files at all. I also moved the reports
initialization and freeing to the constructor and destructor of the
runtime class.
This is the only place `ReportList` was embedded in DNA, so
after this we can move that to use C++ features if we want.
Pull Request: https://projects.blender.org/blender/blender/pulls/118329
ffmpeg's libswscale is used to do RGB<->YUV conversions on movie reading
and writing. The "context" for the scale operation was being created
and destroyed for each movie clip / animation. Now, maintain a cache
of the scale contexts instead.
E.g. in Gold edit, it only ever needs two contexts (one for reading
source movie clips since they are all exactly the same resolution
and format; and one for rendering the resulting movie).
During playback, on some of the "slow" frames (camera cuts) this
saves 10-20ms (Windows, Ryzen 5950X). Rendering whole movie goes
from 390sec to 376sec.
Pull Request: https://projects.blender.org/blender/blender/pulls/118130
This commit essentially:
* Remove the 'delete single ID' code path.
The multi-deletion code has now be around for a long while, so we
should be able to assume it is mature enough. It is also several times
faster when deleting a lot of IDs at once.
* Move away from using `LIB_TAG_DOIT` ID tag in internal code, using a
Set instead to store the IDs to be deleted.
Potential side-effects:
* The 'delete single ID' codepath (removed by this commit) was making
some dangerous assumptions regarding order of IDs in Main and 'strong'
dependencies between them. While these assumptions where presumably
correct in current code/data model context, they were logically wrong
and could have randomly cause bugs in the future.
* The sanitiing check on usercount performed in the case of the single
ID deletion cannot be done anymore. Should not be that usefull
anymore, as there are other places where IDs usercounts are validated.
* Performances:
* The batch-deletion did not show any significant difference in speed.
* Massively deleting IDs one by one however, showed a surprising 10%
speedup.
Pull Request: https://projects.blender.org/blender/blender/pulls/118283
Existing code would allow tagging on request IDs which had a 'never
null' usage potentially cleared by the remapping operation (e.g. if an
Object obdata would have been set to `nullptr`).
While this worked for the current extremely restricted usecase (ID
deletion), this was not the best design, as it forced the ID remapping
user code to be very careful about its own usages of the `LIB_TAG_DOIT`
tag.
This commit replaces internal tagging by adding such IDs to a Set in
`IDRemapper` class, which user code can then use to find which IDs
(would have) had a 'never null' ID pointer cleared.
There are two additional changes induced by this commit:
* `BKE_libblock_unlink` `do_flag_never_null` parameter is removed.
As it is not used in current codebase, simpler to remove than update
the code to support it.
* `ID_REMAP_FLAG_NEVER_NULL_USAGE` option is renamed to
`ID_REMAP_STORE_NEVER_NULL_USAGE`.
In addition, its behavior is slightly modified:
* Before, the owner ID would systematically be tagged if it had such
'never null' ID usages, regardless of whether said ID usages (would)
have actually been remapped to `nullptr`.
* Now, the owner ID is only added to the `never_null_users` set if its
'never null' usages (would) have been cleared.
Span is preferrable since it's agnostic of the source container,
makes it clearer that there is no ownership, is 8 bytes smaller,
and can be passed by value.
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
Currently most of the data stored in `wmWindowManager` is runtime
data not saved to files. It's confusing that it's declared in DNA then. That
also prevents us from using C++ features. This commit adds an initial
runtime struct. Moving data there can be done as a separate step.
Initially I wanted to look at moving the `ReportList` system to C++.
The runtime struct has to be defined in the blenkernel module because
the members are (will be) used there in a few places.
Pull Request: https://projects.blender.org/blender/blender/pulls/118157
The ID remapper code was already largely defined in a CPP struct
(IDRemapper). Make this an actual class, and remove the C API wrapper
around.
This makes the code cleaner, easier to follow, and easier to extend or
modify in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/118146
