Use new `_in_lib` BKE_image API to re-use or load an image from/in the
expected library, including using the library path as root path for
relative file paths handling.
Using the new `BKE_image..._in_lib` API also allows to get rid of the
`check_exists` 'hack' introduced in `image_open_exec` (when support to
edit some linked data was added, in 5f9f3116db) to avoid re-using local
Image IDs for editable linked data (brush assets), since
`BKE_image_load_exists_in_lib` will now ensure to only re-use an Image
ID if it matches the target library.
This commit also simplifies/makes `ED_image_filesel_detect_sequences`
signature more to the point. It replaces the `Main` parameter by a mere
`root_path` string. The given `bmain` was indeed only used to extract
(again) a base for relative paths.
NOTE: The general idea of this fix is the same as in PR !130058, thanks
to Sean Kim for the investigation and initial fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/130197
Previously, we had to fetch all asset previews at once. However the preview
caching system was limited at 8192 previews, so with large asset libraries, many
previews would get dropped. Instead, allow selectively requesting previews and
only request previews of items displayed on screen. This should fix the issue,
and reduce the time it takes to display brush assets in general, especially with
bigger libraries. This should also reduce memory usage quite a lot when
displaying the asset shelf, since not all asset previews are loaded anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/130105
This commit refactors `BKE_image_load` and `BKE_image_load_exists` APIs:
* Remove the `_ex` versions (the 'exist' boolean return pointer can have
default `nullptr` value instead).
* Add `_in_lib` versions, which match signature and behavior of the
generic ID creation code to allow to find or create a new image ID
directly in a library 'namespace' (as linked data).
This is required by upcommig fixes for Brush Assets, which are using
linked but editable data-blocks.
Fix#130194: When trying to add a new image from the UI (e.g. for a new
texture) for a local ID, if that same exact image was already loaded by
a linked ID, it would trigger an assert in `BKE_id_move_to_same_lib`,
because `BKE_image_load_exists` would return the matching linked Image ID
instead of creating a new local one. In release builds with no assert,
it would result in making a linked ID 'local', while still being used by
original other linked data.
Passing around the intended final destination of the new Image (local or
in a given library) allows `BKE_image_load_exists` to be more specific
when searching for an already loaded matching image ID, and ensures that
a new local Image ID is created in the case described above.
Pull Request: https://projects.blender.org/blender/blender/pulls/130195
Partial fix for #129267.
Avoid creating an entry in the file list cache for every asset when iterating
over the available assets. For this, allow passing a pre-filter function to the
asset iterator, to filter based on `AssetRepresentation` data. The asset shelf
can then pre-filter based on asset type and the active catalog.
Really, the cached file entry is only needed to access the preview image of the
asset, so it can be avoided most of the time.
While this should still be solved properly as outlined in #122439, this is
a general improvement and fix the mentioned report in a minimal way.
Was hoping this would be sufficient to fix#129267, but the whole of
!130105 will be needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130166
Caused by 71398478b2.
`parsubstr` is nullptr in Layer struct. This results in crash when an
object is parented to a new layer. This can be fixed by passing layer
member function `parent_bone_name()`. It handles the null pointer.
Pull Request: https://projects.blender.org/blender/blender/pulls/130205
* Early return in case the given `id` is already in the same library as
its target `owner_id` (in addition to both being local data).
* Assert with message AND return in case the given `id` is a linked ID
from a different library.
The second point somewhat mitigates the severity of #130194.
There is actually a valid (rare) case where a Library ID can have a `0`
versionfile value during blendfile loading: if that library only
contains 'indirect weak' linked data.
These IDs are only actually read in the library blendfile if they are
also used by some other data, otherwise they are purposedly dropped and
removed, and the library blendfile can end up never being read at all.
This would lead to a completely empty library on blendfile loading,
which can then be removed from the data-base.
NOTE: this _does not_ affect cases where the whole library is missing,
or some linked IDs from that library are not found anymore.
The data-block selector filters out local data-blocks when trying to
assign to linked data. A lot of data-block management relies on this.
Since these data-blocks are created for the use with brushes only,
create them under the same library that the brush is from, as indirect
data. The UI allows selecting these data-blocks then. We do the same for
textures attached to a brush, and some other data-block types.
Also add paint-curves to the editable data-block types, so they can be
edited despite being considered linked data.
Pull Request: https://projects.blender.org/blender/blender/pulls/130184
The operator to move a channel to the top revered the layer order
by iterating from the top to the bottom and moving selected channels
to the top. Iterate from the bottom to the top instead to keep the right
layer ordering.
Pull Request: https://projects.blender.org/blender/blender/pulls/128793
The cache mechanism for line art is changed during migration to GPv3,
however the code path failed to handle following cases which could lead
to a few problems:
- Line art cache isn't deleted after last line art modifier because it
coule be hidden, causing memory leaks.
- A modifier inside a multiple line art modifier sequence that doesn't
use cache would prematurely delete line art cache, causing subsequent
line art modifier to give empty result.
- When the first line art modifier is hidden (in viewport/render), the
cache is not created correctly, leading to crashes.
Now the new code logic addresses these problems properly by:
- Making sure the last visible line art modifier deletes cache.
- Giving a fresh cache pointer for modifiers that doesn't use global
cache.
- Line art cache is correctly ensured when there are modifiers that
are hidden
Pull Request: https://projects.blender.org/blender/blender/pulls/129953
We need to be careful about not just looking up active tool data from
context, because this code path may also be run from the Properties,
which use the tools of the 3D view. So make sure related code falls back
to the 3D view, like it's already done in some other places.
Caused by removing scene sound from "main scene" when other strip using
the same scene is not rendering sequencer strips.
Only remove sound when all strips using particular scene are not
rendering sequencer strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/129768
The fill tool didn't write to the `fill_opacity` attribute leading
to non-filled strokes in some cases.
This makes sure that the attribute is created with full opacities.
Pull Request: https://projects.blender.org/blender/blender/pulls/130177
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Reverts part of 0872e898bc.
In 4.2, the fill tool had a small paint cursor that could
be turned off using the "Display Cursor" setting.
This makes it so that the cursor for the fill tool behaves
the same as in 4.2.
Turns out the sampling module was not initialized when
computing lighting which resulted in undefined shadow location.
In some cases even producing NaN position which would make the
shadow disappear.
Basically, anything returned by `sampling_rng_nD_get` was returning
garbage, and on some occasion, it could be a negative number and
produce NaN if passed into `sample_disk` or any `sqrt`.
ASAN did not catch it because the uninitialized data load
was done on the GPU.
I ran the render tests and, minor difference aside, they all match.
#### Follow Up:
This raises the concern that we have no assertion for correctly
using some modules. At the very least, we should have some
mechanism to catch uninitialized buffer. Investigating this
was a pain au chocolat.
Pull Request: https://projects.blender.org/blender/blender/pulls/130150
The length modifier was not handling 2 point curves correctly.
This change does two things:
1) Fix the crash by copying the original indices for 2 point curves into `dst_to_src_point`.
2) Fallback to `extend_curves_straight` for extending 2 point curves.
Pull Request: https://projects.blender.org/blender/blender/pulls/130122
The Double Edge Mask node uses too much memory when it is not connected
to anything in the Full-Frame compositor. That's because it tries to
allocate a buffer of size 131072x131072, which is due to the cumulation
of multiple issues.
1. The Full-Frame compositor evaluates nodes that are not connected to
the output.
2. The constant folder assigns a bounds of +-65536 to its output memory
buffers as a maximum possible value.
3. Then the MemoryBuffer::inflate method doesn't know about the constant
folder special value, so it tries to allocate a buffer of that size.
The safest fix for now is to clear the output and return early if all
inputs are single value.
The problem is that this issue might happen for other nodes that also
satisfy the 3 issues above, that is, uses inflate and can be constant
folded. I manually checked for such nodes and there are no nodes that
satisfy all three, so hopefully this is isolated to the Double Edge Mask
node.
Pull Request: https://projects.blender.org/blender/blender/pulls/130163
Mistake in e494a44024
Even though collection/object PointerRNA argument is same in most cases,
use `layer_or_collection_prop` in if() before assigning value to
collection property (`base_or_object_prop`argument value is null in function
call from `_isolate_flag()`).
Pull Request: https://projects.blender.org/blender/blender/pulls/129250
Instead of looping through all drawings in the vertex group kernel
function, loop through all/visible drawings in the operators and
pass a single drawing to `remove_from_vertex_group`.
Continuing !129789.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/129890
Add some missing `nullptr` and `ale->type` checks to ensure the
assmptions the rest of the code makes holds.
The direct cause of this issue is likely
822907a68d. The root cause is the hard to
predict behaviour of the animation filtering system combined with a lot
of pointer casts without testing whether the data is actually of the
expected type.
Pull Request: https://projects.blender.org/blender/blender/pulls/130148
`set_active_node` call from `grease_pencil_copy_data` resets inactive
layer again as locked before executing the drawing code. Since property
is only operated on layers, it is possible to remove the code from
`set_active_node()` and only have it in `set_active_layer()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/129465
The Merge-Down operator for layers was inserting existing layers first,
then appending the 2 merged layers at the end (top of stack).
Now merged layers are inserted at the position of the layer below the
active, so the layer order remains unchanged.
Note that merging a layer group has a similar issue, with the new
layers getting appended at the top. This is a bit more difficult because
looping only over layers drops the relative ordering of groups and
layers. A separate fix is needed for that.
Pull Request: https://projects.blender.org/blender/blender/pulls/130146
When a layer group was active, new groups would be created at
the top of the layer tree which is inconsistent with how layers are
added.
This fixes the behavior. When a group is active, newly added groups
are moved into that group.
The code that was updating the active node after removing a layer/group
was not handling all cases correctly.
The fix updates the logic for setting the active node:
1. If the node is a non-empty group and we're keeping the children, then set
the active node to the top node in the group.
2. Otherwise, if the node has a node below it (in the same group), set it to be the active one.
3. Otherwise, if the node has a node above it (in the same group), set it to be the active one.
4. Otherwise, if the parent is not the root group, set the parent to be the active node.
5. Otherwise, clear the active node.
This behaves the same as in Krita.
Pull Request: https://projects.blender.org/blender/blender/pulls/130126
The code was relying on the layer cache through `groups_for_write`/`layers_for_write`.
The `group->runtime->layer_group_cache_` stores all the child groups instead
of groups on first level. This leads to crash when recursively deleting
group i.e. group at third level has been deleted but `layer_group_cache_`
of first level group will still point to address of freed memory.
The fix removes the use of the cache and iterates over the direct
children in `group.children` and deletes them recursively.
Pull Request: https://projects.blender.org/blender/blender/pulls/130082
The PBVH vertex positions accessor functions have to match the logic in
`sculpt_update_object`. When there were topology changing modifiers
before deform modifiers it didn't. `BKE_crazyspace_build_sculpt` just
skips the topology changing modifiers, and the resulting positions
are stored in `ss.deform_cos`, which we need to access here.
Pull Request: https://projects.blender.org/blender/blender/pulls/130139
The Join operator for Grease Pencil was making a shallow copy of the drawings
array, with the assumption that the source object would no longer be needed.
This is not the case, the source object is still in the blend data and still
shares the same drawings pointer as the target object. This is invalid, the
drawings should owned by one object.
To fix this the patch makes a deep copy of the drawings so the source and target
have their own sets of drawings. Data is still shared at the CustomData level,
so these copies are not very expensive.
Pull Request: https://projects.blender.org/blender/blender/pulls/130140
Check the error status from the function that updates the active vertex.
Also add `PROP_HIDDEN` to the operator's properties so the redo panel
doesn't show; that seemed extra weird to display on failure.
Pull Request: https://projects.blender.org/blender/blender/pulls/130142
When the duration of a frame is shorter than the build time specified in
the modifier, build modifier should shorten the build time to allow the
frame to be fully built within the frame duration. This fix made the
timing behaviour the same as GPv2.
Pull Request: https://projects.blender.org/blender/blender/pulls/129894
Essentially, any operator modifying Blender data should enable this
`UNDO` option, else bad things (corruption, crashes...) are likely to
happen.
* Added a new Operator example to explain this topic.
* Updated some existing Operator examples that were not correct anymore.
* Added a new small section in the gotchas page linking to it.
* Added also short reminder about this in the `UNDO` 'tooltip'
description itself.
Related to #77557.
This was added 7 years ago as 'safe' preservation of previous behavior,
when ID copying was refactored and more control was added over its
behavior.
However, it was never removed since then, even though `NO_PREVIEW` flag
has been part of the `LOCALIZE` copying behavior since many years.
So time to remove this enforced bahevior and use the API as designed. If
this causes new issues, they will have to be fixed in code calling the
ID copy API (most likely by simply adding the `NO_PREVIEW` flag to the
copy options).
The snap cursor internally snaps to the Face to define the occlusion of
the Grid or to calculate the "Surface" orientation set by the tool.
Even though this is not the snap point enabled by the user, this
internal Snap to Face takes precedence over the Snap to Grid that is
enabled by the user.
To solve this, the solution is to do a second snap test but now only to
Grid and using the hit point as a reference for the closest grid.
Also fixes Absolute Increment Snap not being detected as Grid by the
tool.
Pull Request: https://projects.blender.org/blender/blender/pulls/130092
This was caused by ba28469e, which subtracted the start of the
offsets array, so it can't be used for "max array size" any more.
Use the "last()" entry directly to correctly size the view
positions array.
Pull Request: https://projects.blender.org/blender/blender/pulls/130127
