There are still node versioning bits running after linking, for example
`version_geometry_nodes_replace_transfer_attribute_node`. This code
relies on node types being untouched at that point.
Move the unknown node type replacement from `ntreeSetTypes` into the
`ntreeUpdateAllNew` function. This is called _after_ late versioning.
Pull Request: https://projects.blender.org/blender/blender/pulls/121773
Depthdropper should ensure that the viewport is in camera view to use
active camera position, otherwise it should still use rv3d->viewinv[3]
to ensure correct distance result.
Pull Request: https://projects.blender.org/blender/blender/pulls/121339
The issue seems to be caused with the recent NVidia drivers, which will
crash if OptiX context is created prior to the OpenGL context on Linux.
This happens with drivers 545.29.06, 550.54.14, 550.67 and kernel 6.8
on Ubuntu 24.04, and also happens with NVidia driver 550.67 on Gentoo.
While it does seem the issue is likely on the driver side, the timeline
for it being resolved there is unknown. Until then it is possible to
apply workaround on Blender side, which will initialize GPU context
prior to rendering with an external render engine when it is known the
GPU context will be needed later on.
Note this is not a complex fix, because in general it's still possible to
render a frame without and then with grease pencil, in which case OptiX
will still be initialized first. But we don't want to always initialize
OpenGL, and we can't predict future operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/120026
Buttons for mesh symmetry on the toolbar, and other buttons of the same
functionality located in other areas of the window, weren't updated when
clicking on them.
Pull Request: https://projects.blender.org/blender/blender/pulls/118508
Although rare (and not recommended!), it can happen that a same exact
RNA path points to a different type of data.
This can come from an update of the code itself, but this is very
unlikely and discouraged.
However, geometry nodes and their 'modifiers' interface have made it way
more easy to create such conflicting situation, since users are free to
re-arrange and edit the nodes and their 'public' interface as they
want...
Found out while investigating some unrelated issues in some studio Gold
production files (namely,
`pro/shots/090_joining_whale/090_0130/090_0130-anim.blend` r2110
exhibits such issue for `OBGEO-mika-body`
`modifiers["RIG-GN-mask-clothing"]["Socket_3"]`, where the RNA type
changes from integer to bool).
NOTE: Cherry-pick of 6adf5adb7f, had to do some non-trivial changes to
get it to work in older code though.
Pull Request: https://projects.blender.org/blender/blender/pulls/119429
Pull Request: https://projects.blender.org/blender/blender/pulls/119687
Second issue reported in the comment was caused by some shapekeys
flagged as embedded liboverride data, when their owner ID (Mesh e.g.)
is not a liboverride at all.
The `BKE_lib_override_library_validate` called on file read was only
covering real liboverride IDs, which where then supposed to take care of
their own embedded data. But since the owner ID is already a full
non-override ID, its embedded data ended up never being properly
sanitized.
Most likely more corruption data from quite old files and/or deprecated
experimental features.
`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.
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
