Caused by 9c1da81a4c.
This happened in the case where objects shared the same data and slots
are assigned to object and receiving object did not have a material slot
yet.
Then, `ob->matbits` may be NULL, now just check for this, too.
Pull Request: https://projects.blender.org/blender/blender/pulls/119161
A missing part since PR #110139: the nodes and relations builders
needs to be in-sync and build the same objects. The relations builder
was missing relations building for camera referenced by markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/114443
When linking a collection from library, it can be linked inside another
linked/overrided collection if it is selected in outliner. This can be
prevented by linking with editable parent collection.
Pull Request: https://projects.blender.org/blender/blender/pulls/119144
One of the consequences of the mistake in 3fcf535d2e (fixed in previous
commit), was that the more recent `LIB_EMBEDDED_DATA_LIB_OVERRIDE` ID
flag could be wrongly set in some nodetrees from pre-2.76 blendfiles.
This commit adds a check that embedded IDs flagged with
`LIB_EMBEDDED_DATA_LIB_OVERRIDE` are actually embedded IDs of a
liboverride.
Pull Request: https://projects.blender.org/blender/blender/pulls/118921
In 3fcf535d2e, the `ID.flag` data was split, keeping persisten flags in
`ID.flag`, and moving runtime ones into a new `ID.tag` data.
Some versionning code was then added to cleanup the existing `ID.flag`
on file read, but embedded IDs (root node trees only, back then) are not
stored in Main data-base, and were skipped.
Note that this fixes the conversion of older (2.76.4 and older) files.
There is no reliable way to cleanup files opened and saved from more
recent versions of Blender unfortunately.
HIP fails to allocate textures, typically when they are too large.
This commit lets the user know what might be causing the issue
rather than providing a confusing internal error message.
Pull Request: https://projects.blender.org/blender/blender/pulls/118239
Problem here is that when selecting/activating an object in a different
scene in the Outliner, the Outliner will automatically switch scenes via
`WM_window_set_active_scene` however the `view_layer` was untouched and
as a consequence `BKE_view_layer_synced_ensure` gets the right scene but
the "wrong" viewlayer [which makes it not do its thing properly]
To solve, now use the new active viewlayer after having switched scenes.
NOTE this also solves a couple of other asserts elsewhere (when not
deleting, just selecting/activating could assert on
`DEG_is_evaluated_object(ob)`)
Pull Request: https://projects.blender.org/blender/blender/pulls/118458
The intend in the report was to rename a linked object in the NLA
channels. The operator to rename actually does everything right, it
detects that the object is linked and passes through to other operators.
The crash then happens in the attempt to select keyframes of channels
(also doubleclick n the keymap) -- in `select_anim_channel_keys`.
The problem is that `bAnimListElem` `key_data` cannot be expected to be
an `FCurve` in all cases. Code does though, it always casts, but this is
unreliable, basically this would fail for all of the "summary" channels
or any channel type (e.g. mask layers etc.), either it is NULL or
garbage data.
So to resolve, we just check the `bAnimListElem` type -- if it is not
ALE_FCURVE we can early out (preventing the crash).
NOTE: this changes behavior of double clicking on a summary channel that
cannot be renamed slightly in that it will not deselect its keys anymore
(it was not selecting any keys anyways, this is actually more in line of
what would happen if you just select another channel -- this also leaves
key selection alone -- so this is actually an improvement as well imho)
Pull Request: https://projects.blender.org/blender/blender/pulls/118251
Currently, the OpenEXR reader can't read single-layer XYZ images as a
combined image. Single-view images will only read the X channel, while
multi-view images will interpret the Z as a depth image and the Y and Z
channels will be treated as float passes.
This patch allows the reading of XYZ channels as combined images. For
single-view images, we just extend the RGB-like channel names we match
to contain XYZ. For multi-view images we only treat the Z channel as a
Depth one if no X and Y channels exists, since the Z in this case is
part of the XYZ image.
Pull Request: https://projects.blender.org/blender/blender/pulls/115290
Currently, the EXR reader only considers uppercase RGBA channel names in
single-layer EXRs, which leaves out the lower case rgba channel names we
started using for data and vector passes in Cycles and the compositor.
Further, a single V channel was also ignored, which is by convention
used for BW passes.
This patch extends the single-layer channel recognition methods to
include lowercase rgba and V channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/114339
The `make update` will now always update all initialized submodules,
including the library ones.
The `make_update.py --no-libraries` will neither initialize nor update
pre-compiled libraries or tests.
This is a cherry-picked #118812 onto the 3.3 LTS branch.
Pull Request: https://projects.blender.org/blender/blender/pulls/118816
This change makes it so build system and update utilities for Blender builds
are using pre-compiled libraries and other resources attached as Git modules
instead of using checkout of SVN repositories in the parent folder.
The directory layout:
```
* lib/
* darwin_x64/ -> lib-darwin_x64.git
* darwin_arm64/ -> lib-darwin_arm64.git
* linux_x64/ -> lib-linux_x64.git
* windows_x64/ -> lib-windows_x64.git
* tests/
* data/ -> blender-test-data.git
```
The changes about configuring the actual Git sub-modules are not included
into this patch, as those require repository to actually exist before it
can be used.
The library and tests data submodules are disabled by default. This means
that if someone runs `git submodule update --init` they will not get heavy
libraries. The platform-specific and tests related submodules are enabled
when using `make update` or `make test`.
All the new submodules are tracked: this means that when new commits are
done to the submodule, the blender.git repository is to be updated to
point them to the new hash. This causes some extra manual work, but it
allows to more easily update Blender and its dependencies to known good
state when performing operations like bisect.
Ref #108978
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118740
Underlying `lib_override_library_resync` code lost the optional aspect
of its `view_layer` parameter at some point, trivial to restore it
luckily.
3.3-specific version of original fix (711e4cdd94).
Pull Request: https://projects.blender.org/blender/blender/pulls/118364
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.
`BKE_library_id_can_use_filter_id` was missing the ShapeKey type for
geometry IDs (meshes, legacy curves, and lattices), leading to the
remapping code to fail to do its job when deleting the ShapeKey only.
Pull Request: https://projects.blender.org/blender/blender/pulls/118281
Convex hull calculation would "cap" line segments with the first point.
Besides causing a buffer overflow when passing in two points,
it's not needed as matching first/last ends aren't expected
to be set by this function.
Without doing a stroke "manually", colorspace initialization on
UnifiedPaintSettings was never done.
This lead to wrong colors in the past, since modern CS code with OIIO
this also crashes.
Colorspace was added into UnifiedPaintSettings in 6f153046e0 to avoid
doing this when sampling the brush texture images [which is good], but
the initalization was done in `paint_brush_update`.
We dont need to have this called for every step (it was skipped anyways
after one run), so it seems we can move this out of `paint_brush_update`
and put this into `paint_stroke_new`.
Thx @RevDr for initial findings.
This is because the `NODE_OT_group_edit` operator reuses the last value
of the `Exit` property and once this is set it would always try to pop
(instead of push [which is what we want from the icon]) the nodegroup.
Callers of the operator set `Exit` explicitly elsewhere (just not
from node drawing -- where the way it is called [via a more general
callback] makes it difficult to set operator properties from there).
Solve by not saving the property for following usages (flag
`PROP_SKIP_SAVE`).
Fixes#117530.
Pull Request: https://projects.blender.org/blender/blender/pulls/117542
By default, Color Palettes are only drawn in the UI in the context of
**painting**.
UI button code then tries to update an appropriate brush from edits to
the palette.
So a valid `Paint` and `Brush` were assumed. This is not a problem for
objectmode (because `BKE_paint_get_active_from_context` then defaults to
`ImagePaintSettings`'s `Paint`), but other modes dont guarantee this
(editmode only returns a valid `Paint` when uv sculpting).
In the report, a palette was created and displayed via python, making
changes in editmode would then crash.
Solve by checking we have a valid Paint in corresponding UI code to
begin with.
Similar to 9e82e48937 .
Pull Request: https://projects.blender.org/blender/blender/pulls/117544
This has been broken since 2.8.
The highlevel reason for this is that the "info file" (saved as frame
zero) was not written anymore.
Reason for that in turn is that when calling BKE_ptcache_write outside
the bake job, the PTCacheID calldata (a psys in our case) is not the
evaluated particle system, causing a check for totpoint to fail (these
were always zero).
Deeper reasoning is unclear, no further investigations were done as to
why/when this happened.
The solution proposed here is using the evaluated psys when writing the
info frame (and this is isolated to just this spot and only to particle
systems). File then gets
written and can/will be read when using this as an external disk cache
in another file.
Pull Request: https://projects.blender.org/blender/blender/pulls/117401
Caused by e968b4197b / 67e23b4b29
Since culprit commits, we are not running `MANTA::initGuiding` /
`fluid_alloc_guiding` if guiding is meant to be pulled from other
domains (it does work with effectors though). This is because atm. only
the `FLUID_DOMAIN_ACTIVE_GUIDE` flag sets `mUsingGuiding` to true
(activated in `update_obstacleflags`, so only for effectors).
So to fix this, we have to ensure that `MANTA::initGuiding` runs (also
if guiding is pulled from domains), but also make sure we dont run into
the crashes from T102257.
It seems that the real reason we were getting crashes in T102257 is that
67e23b4b29 made it so that resetting the cache (including a call to
`fluid_modifier_reset_ex`) in `fluid_modifier_processDomain` happens
**after** `FluidDomainSettings.active_fields` have been updated (this
happens in `update_flowsflags` & `update_obstacleflags`).
But `fluid_modifier_reset_ex` also resets
`FluidDomainSettings.active_fields`. If we then update pointers later in
`fluid_modifier_processDomain`, we never get anything in the guiding
related pointers for the new `mCurrentID` (specifically `mPhiGuideIn`
will be a nullptr). This is the real reason `initGuiding()` runs a
second time (it does once for `fluid_modifier_init` then again as a
consequence of the call to `manta_guiding`).
This patch proposes to move the resetting process from 67e23b4b29
**above** the refreshing of the `FluidDomainSettings.active_fields`,
this way these field stay intact, we do get the first run of
`initGuiding()` from `fluid_modifier_init`, manta pointers get updated
with intact fields afterwards (so we then get a valid `mPhiGuideIn`),
which then prevents the second run from `manta_guiding` to actually call
the python script again.
The fix from e968b4197b is then not needed and reverted in this patch.
This should be good for LTS I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/117067
While the shortcuts would be shown for menus & panels,
there was no way to edit them from the context menu.
This was reported as a bug since moving "Undo History" from an operator
to a menu meant it was no longer possible to assign a shortcut from
the context menu.
Resolves: #97431.
There is currently a bug with autopep8 and Python 3.12, resulting in
the contents of f-strings getting modified when they shouldn't.
As a workaround, "make format" now uses the Python binary bundled with
the precompiled libraries on Linux by default. This matches existing
behavior on macOS and Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/116993
There were two issues at play here.
The first is that only enum properties with raw array access were
supported.
The second is that if the item property pointer was found immediately,
`rna_raw_access` could fall back to the slower loop without checking if
the property was an enum property, which the slower loop did not
support. This would cause the code to go through the entire slower loop
without doing anything. In the case of `foreach_get` without a
compatible buffer, this meant that the temporary, uninitialized array
(which was supposed to be set by `rna_raw_access`) would be converted to
Python integers, causing garbage values to be retrieved by
`foreach_get`, since they were created from uninitialized memory.
This patch adds support for enum properties that are not arrays and adds
asserts if an enum array property is encountered because they do not
exist.
Additional unreachable asserts have been added to the default case of
each switch block within the slower loop because there are prior checks
that the property type is supported, so the switch blocks should never
get an unsupported property type.
Pull Request: https://projects.blender.org/blender/blender/pulls/115508
