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
Relatively basic and straightforward implementation.
Further optimizations are possible (and needed), especially regarding
the handling of caches.
Notes:
* All drawings are stored in each undo step. This is needed (also for
Reference drawings), in case some drawings are added, removed or
re-ordered between undo steps.
* The whole tree of layers is copied as-is, using the C++ classes copy
constructors, so they only handle what these constructors copy
(noticeably, the `Layer` copy constructor does not currently handles
masks?).
* The active layer pointer is stored and restored by its name.
* The layer customdata is also duplicated using standard `BKE_customdata`
API.
Pull Request: https://projects.blender.org/blender/blender/pulls/117072
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.
This PR adds a new command line argument to validate all statically
defined shaders. It is useful for platform support to understand
what isn't working.
It only checks statically defined shaders. Dynamic shaders (EEVEE/Compositor)
can still be fail.
The report is printed to console. After checking with windows platform and
triaging we could also add it to gpu debug script. There is a risk of adding it there
as it might crash and don't store any output.
Pull Request: https://projects.blender.org/blender/blender/pulls/117326
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
The tiled compositor code is mainly still around, which is only
expected to be a short-lived period. Eventually it will also be
removed.
The OpenCL, Group Buffers, and Chunk size options are already removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118010
