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.
These were last used in some sculpt code that has been refactored
to do things more efficiently. For that same reason I don't think we're
likely to need them elsewhere.
OBJ, PLY, and STL used a mix of fprintf, std::cout, and std::cerr to
trace warnings, errors, and general messages to the console.
Now, we instead use CLOG which provides real facilities for warnings and
errors and generally removes the need to pull in and use the heavy
`<iostream>` machinery.
For traces that should always be printed, `fmt::print` is used since
CLOG currently doesn't provide that particular level of trace.
Tests were only minimally changed to drop usage of streams while keeping
their prior usage of older stdio APIs. We can change to using fmtlib
there too if desired.
Pull Request: https://projects.blender.org/blender/blender/pulls/130107
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
Brush assets from the current file should be supported like other brush
assets.
This assert would fail on startup for example, when opening the
essentials file containing the default brush of this mode.
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
In some cases the MTLContext was being destroyed before all GPU work was completed causing the (outstanding) command buffer completion event handler to update a command buffer that had already been freed. This behaviour was introduced by [this](https://projects.blender.org/blender/blender/commit/6da42e9c951b) change which updated the event handler to track the number of outstanding command buffers per context as well as system-wide.
Reproduced the issue with ASAN enabled and confirmed that waiting for the GPU to complete fixes the issue.
Also contains a minor fix for unitiiliased values in MTLAttachments identified by ASAN.
Authored by Apple: James McCarthy"
Co-authored-by: James McCarthy <jamesmccarthy@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/129686
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
This is replacement of a too specific function to copy attributes from a grease pencil to instances.
With #127026 there is no more reason to have such a specific implementation so general `copy` is used now.
Pull Request: https://projects.blender.org/blender/blender/pulls/127027
