Only create an outliner tree element for all Action slots in specific
modes of the outliner. The "object-hierarchical" modes (Scene, View
Layer) show the Action underneath each user of that Action; in these
cases, only the assigned slot is shown now.
Previously all slots would be shown, in all modes of the Outliner. This
meant quadratic complexity, as each Action is included in the tree for
each of its users, and then each of those tree items would show all
slots. This means the number of tree items for the slots was multiplied
by the number of users.
Pull Request: https://projects.blender.org/blender/blender/pulls/144864
In the Node Editor itself, you cannot edit a linked Nodetree (add nodes,
drag from a socket etc., so basically no actions allowed).
In the Properties Editor (Material tab) however, where we display the
Nodetree differently (via `uiTemplateNodeView`) and while editing
properties themselves was already disabled, you could still edit node
**links** (thus **adding** nodes to the tree).
This would all be lost on file reload though, so better prevent this.
To resolve, just disable the socket / NodeLink button when looking at a
linked Nodetree.
NOTE: the "not in a linked nodetree" disabled hint is not showing yet,
something I intend to fix in an upcoming PR (it is also not showing this
for properties generally in the node editor).
Pull Request: https://projects.blender.org/blender/blender/pulls/144930
* Bundled ICC profiles for display spaces supported by Blender, and
embed them in the image file when saving.
* Verified to work for PNG, TIFF, JPEG and WebP, but not all file
formats support this.
* No ICC profile is written for sRGB currently. It would be a matter
of adding an icc file, however this may be a breaking change for
some use cases.
* Fix save as render of EXR files not properly changing the image
colorspace to match.
Uses CC0 licensed ICC files from the Compact ICC Profiles project.
This does not include support for saving HDR images. While there exist
ICC profiles for PQ, they are not well supported and the preferred method
for HDR is to write CICP tags. However OpenImageIO support for this is
still under development.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
These should at least show the correct colors and gamut now, following the
color picking space in the OpenColorIO config.
However the ACES config use sRGB as the color_picking role, which means
that the color picker only shows a limited a gamut. There is apparently is
not agreement on the interpretation of this role, so we might have to stop
using it.
Additionally, if you set the color_picking role to something like ACEScg +
sRGB transfer function, the widgets do show all the colors in the gamut,
however the gamut is probably too large to be practical for most uses. So
we need some UI solution for this regardless.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
This was a temporary solution until we had proper HDR displays.
* Auto detect from the display + view transform if they are HDR, and
enable it automatically. This is based on encoding hdr-video in the config.
* If a HDR transform is selected and there is no HDR display support, an
info message will be shown in the color management panel.
* It is now possible to view HDR images in the image editor, without
needing to use "View as Render".
* There is no versioning to switch to a HDR display, because that also
affects image saving. So users will have to manually select the
"Rec.2100 PQ" display to see HDR colors again.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
* Change meaning of display device to be the device that we are trying
to emulate, not the monitor configuration.
* The display transform is now:
* User specified view and display transform
* Clamp to 0 to limit colors to gamut
* Inverse untonemapped display transform
* Convert to extended sRGB
* When using the display space in the color management API, it now needs to
be specified if it's for drawing (with emulation) or file output or color
inspection (without).
Like HDR, this only works on macOS and Linux + Wayland + Vulkan currently.
Support for Windows/Vulkan is under development in #144717.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
For display and image saving, we need to know certain properties of displays
and view transforms that OpenColorIO does not explicitly provide. In the
upcoming OpenColorIO 2.5 there will be an interop ID for color spaces that
adds more information. This moves towards that design, with heuristics for
configs that don't have the interop IDs.
* Try to use the first colorspace alias as the interop ID. This is used in
some existing configs, and now the Blender config as well.
* Improve ACES 2.0 config compatibility by interpreting some aliases like
srgb_display as interop IDs.
* Detect is_srgb and is_wide_gamut through display colorspace interop ID.
These are now per view rather than per display.
* Detect is_extended where we can't clamp to 0..1 through interop ID.
* Detect untonemapped view as config wide default view transform for converting
between reference and display space, if "Standard" or "Un-tone-mapped" can
not be found.
* Detect which display and view transform combination is HDR by checking for
"hdr-video" encoding on the display colorspace in the OpenColorIO config.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
* PROP_COLOR_GAMMA is sRGB, not display space
* Hex colors are always sRGB
* Image byte buffers are in byte_buffer.colorspace
Fixes for sequencer text, image painting, render stamp and tooltips.
The default display space is sRGB, so this change will not be noticed
in most files.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
DEG_add_collision_relations was only adding relationships for objects in
the brush collection, however dynamic paint also updates parent objects
and armature poses which weren't accounted for. Failing to include these
relations meant the evaluating the depsgraph could evaluate a pose
object from multiple threads at once - causing a crash.
Resolve by sharing logic between DEG_add_collision_relations &
BKE_object_modifier_update_subframe so depsgraph relationships match
objects the dynamic-paint modifier updates as part of its evaluation.
Ref !144844
Improve the documentation for the Bone coordinate spaces and these struct fields:
- `head` & `tail`
- `bone_mat`
- `arm_head` / `arm_tail`
- `dist`
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/143729
When unlinking object from unused data display mode, crash occurred due
to dangling pointer (`id->lib->runtime`) of parent tree element. Here
parent is "Objects" tree element which is not an actual ID. Similar to
other unlink callback, add an extra check to ensure we're unlinking from
valid ID/tree element.
Pull Request: https://projects.blender.org/blender/blender/pulls/144853
This is a workaround for an issue in SPIRV-Optimizer. When optimizing
large shaders the optimizer can crash. This can be fixed by altering the
maximum object ids and performing a compact ids in the end. However this
part of the API is not accessible via ShaderC.
To work around the issue shader optimizations are being disabled for
large shaders. The issue has been reported upstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/144774
In `init_submission_pool`, the submission runner was started before
initializing the queues it uses, leading to a race condition that could
result in a crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/144795
This patch generalizes node tree subtypes to be usable for node trees
other than Geometry Nodes. In particular, this:
- Renames SpaceNode.geometry_nodes_type to node_tree_sub_type, which now
store a tree type-specific enum.
- Renames SpaceNode.geometry_nodes_tool_tree to selected_node_group,
which now stores any context-less tree of any type.
This breaks the python API due to renaming.
Pull Request: https://projects.blender.org/blender/blender/pulls/144544
Attaching mipviews directly on a framebuffer results in a driver crash.
Letting the backend handle the mipviews works around the issue.
This fixes the crash, but seems to point to an issue when attaching
mipviews directly. It also ensured that the shader bound mipviews
cannot be destroyed when new mipviews are ensured.
Pull Request: https://projects.blender.org/blender/blender/pulls/144796
The existing suppression from [0] wasn't working for release builds.
Explicitly suppress the warning instead of using a dummy check.
Ref !144898
[0]: 9ad46ebd2f
When `--gpu-vsync` & `--gpu-compilation-subprocesses` received invalid
arguments, they weren't skipped (typically an attempt to load them as
a bland file would be made).
The prior naming is a bit confusing given that it returns `true` if
`brush` is `nullptr`. My initial expectation on reading the old name is
that it would only return true if both are non-null.
Pull Request: https://projects.blender.org/blender/blender/pulls/144822
Currently, sequencer structs contain several pointers to data within
other structs. These pointers need to be remapped as the structs are
reallocated when reading from blend files. That has worked so far
because the pointers are exactly the values from the Blender session
that saved the file. WIth the implementation of #127706, the pointers
in the file aren't "real" anymore, and we can't offset them to get the
struct that contained the data.
This commit replaces these 4 mid-struct pointers to point to the
containing strips instead, and uses some trivial logic to access the
fallback root sequence channels and strips. This makes the pointer
remapping on file load possible again.
The downside is that this isn't strictly backward or forward compatible,
but only on a UI-level. The active meta-strip information will be lost,
and the sequencer will reset to displaying the root sequence.
Depends on #144624
Pull Request: https://projects.blender.org/blender/blender/pulls/144626
Alternative to #144563.
This fix adds a lock to the runtime data, and holds the lock whenever the
brush mesh is accessed. While there may be more efficient solutions,
dynamic paint is at the end of its life and guaranteeing correctness is
more important.
Pull Request: https://projects.blender.org/blender/blender/pulls/144816
The crash is caused by libepoxy GL functions pointing to nullptrs.
libepoxy "Automatically initializes as new GL functions are used.",
so to call a function without a GL context bound, the function must
have been called before with a bound context.
This PR ensures there's a valid GL context bound for the whole
`WM_exit` scope.
(4.5 backport candidate)
Pull Request: https://projects.blender.org/blender/blender/pulls/144572
