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.
- Use FunctionRef to avoid passing a separate user_data pointer
- Use std::string in arguments struct
- Add search items in one loop after gathering search items
- Use Vector of unique_ptr for search items instead of linked list
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.
It is not required to hold the lock of DST when performing
compositing on GPU, as the compositor implementation uses the
GPU module directly, bypassing the draw manager.
However, currently this is known to cause issues on macOS,
and is not yet tested on Windows.
On Linux it works correctly, and avoids lock while compositor
is running.
There could still be a small locking hiccup, when the GPU
context is created and disposed. This needs to be looked
into.
Pull Request: https://projects.blender.org/blender/blender/pulls/118286
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 Realtime Compositor uses the CPU compositor. That's because the enum
identifier of the Realtime Compositor changed to GPU, so update the test
script accordingly.
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
This improves the volume probe resolution and
dimensions to envelope most test scenes.
This doesn't increase the baking time
that much as most of the baking time is
spent compiling shaders.
These are now included in the OSL shared libraries, so no reason to
link against it.
The CMake code for WITH_LLVM remains in case it is useful in the future,
but is not enabled by any Blender feature now.
Pull Request: https://projects.blender.org/blender/blender/pulls/118229
Caused by previous change for full-frame compositor.
The determine_canvas() is still used by the tiled compositor,
so restore it to the state which makes both compositors to work.
Pull Request: https://projects.blender.org/blender/blender/pulls/118254
This aligns the node behavior to GPU compositor.
The implementation is a bit of a stretch of the full-frame
constant-foldable operations, but this is as good as it can
get in a short time.
The alternative could be to somehow inject a SetValue
operation, but since it expects ahead-of-time known value it
is not as straight forward.
Pull Request: https://projects.blender.org/blender/blender/pulls/118248
