Previously, this code would crash when there are vertex groups which are
not stored as simple arrays. This happened e.g. in #124416.
All non-array attributes are converted to array-attributes with this change
for now, which is better than crashing.
Issue was that the left mouse press event was handled to activate the
dragging state, but not "consumed". So general view item handling would
attempt to force-activate it again, exiting the dragging state
immediately again.
Consume the event now, plus handle properly any similar unexpected cases
(with failing assert), where modal state would be exited because of an
unconsumed event.
Alternative solution to #124529, thanks to Pratik Borhade for finding
the root of the issue.
The Sun beams node produces sharp results when the background has an
alpha channel. That's because the sun beams samples were weights by the
alpha channel, and when the image is mostly transparent, no smooth
falloff can exist.
This is a regression in the Sun Beams redesign that took place in v3.6.
I was mislead by the fact that the alpha was multiplied to the weight.
But the original code actually multiplied the alpha of the border color,
not the sample color. So this fix essentially restores the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/124532
The vector pass and potentially other vectors that store 4 values are
stored wrongly, in particular, the last channel is ignored. To fix this
we identify if a vector pass is 4D and store the information in the
result meta data, then use this information to either save a 3D or a 4D
pass in the File Output node.
This is a partial fix for the GPU compositor only. The complete fix for
the CPU compositor will be submitted separately as it is not
straightforward and will likely require a refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124522
The swapping code incorrectly expected the link to have a start and end.
However, this was not necessarily the case when attempting to create
a link from a node to itself. This case has special handling in
`node_link_find_socket`.
This changes the type of `new_id_to_item` from `GHash` to
`Map<ID *, BlendfileLinkAppendContextItem *>` which simplifies code. For this to work
nicely, `BlendfileLinkAppendContext` had to become a non-trivial type. Since it
was allocated with `calloc` before, I gave all members
zero-default-initializers.
This also changes `BKE_blendfile_link_append_context_new` so that it uses
`MEM_new` instead of allocating the `BlendfileLinkAppendContext` as part of the
memory arena, because that's the more common way to do it, and it does not seem
like saving this one allocation here makes a difference considering how this is
used.
Pull Request: https://projects.blender.org/blender/blender/pulls/124516
Previously, grease pencil was just ignored by the Join Geometry and Realize
Instances code. Now they work by concatenating the layers of all grease pencil
geometries together. So if e.g. there are two inputs with each 3 layers, then
the output will have 6 layers. Layer attributes are kept intact.
Some important things to keep in mind:
* Grease pencil layers are expected to have unique names. Ensuring uniqueness
requires O(n^2) currently.
* The material indices on the curves in each layer have to be remapped.
Just like with all other geometry types, the first input in the Join Geometry
node will come first in the output geometry. Since grease pencil layers are
drawn starting at index zero, that means that the first input will be drawn
first (i.e. it's at the bottom).
Pull Request: https://projects.blender.org/blender/blender/pulls/124361
The Cryptomatte layers in the compositor are saved compressed and saved
in half precision in the File Output node. That's because the EXR writer
makes decision about compression and half float based on channel names.
And Cryptomatte are currently saved using RGBA channel names like other
color images.
To fix this, we follow the Cycles convention of using lowercase rgba for
Cryptomatte images, allowing them to be saved without compression and
always in full precision since they are otherwise useless.
Fixes#124208, #87988.
Pull Request: https://projects.blender.org/blender/blender/pulls/124508
The call to `GHOST_DisposeSystemPaths` was done in `WM_exit_ex` and
_some_ of the tests' 'teardown'. But some more where missing. Issue was
only reproducible when defining `WITH_CXX_GUARDEDALLOC` cmake option.
There are several layers of issues here, this commit addresses the
first, simplest one: since `BKE_appdir` API will indirectly create the
GHOST SystemPaths data, it is simpler and more logical to move the
deletion of this SystemPaths data in `BKE_appdir_exit()`. This avoids
exposing a fairly low-level implementation detail all over our codebase.
Further more, `WM_init` also does not need to explicitely call
`GHOST_CreateSystemPaths`, since it will be created automatically when
required.
Since 4a9e8087a7, preview-tile buttons are non-interactive by default,
so tooltip handling is not triggered. Instead, attach the tooltip to the
underlying view-item button.
This commit creates an operator to convert a `legacy Action` into a `layered Action`.
No data is destroyed, the operator creates a new datablock.
The conversion to the `layered Action` is lossless.
Pull Request: https://projects.blender.org/blender/blender/pulls/122043
Caused by a060e96103
This change restores the old behavior of pass name detection from
channel name prior to the offending commit.
The fix includes regression test based on the files from related
reports, to help catching possible issues in the future.
Being so close to the release this commit restored behavior prior
to the previous fix. Potentially this makes some files to detect
wrong pass name for some specific files, although it is not really
clear if such files exists in the wild.
Pull Request: https://projects.blender.org/blender/blender/pulls/124458
This patch adds support for meta data in the GPU compositor much like
the mechanism that already exist in the CPU compositor. Only Cryptomatte
meta data is handled at the moment because that is the only meta data
that the compositor supports.
The is_data member of the result was moved to the meta data structure for
consistency with the CPU compositor.
Fixes#124222.
Pull Request: https://projects.blender.org/blender/blender/pulls/124460
Instead of hard-coding `IDType_ID_AC.dependencies_id_types =
FILTER_ID_ALL`, which is overly broad, determine its value dynamically
in `id_type_init()` so that it's purely based on which `IDType`s
identify as 'animatable'.
This should make things like ID remapping a bit more efficient, as the
remapping code knows that an Action will only reference animatable
data-blocks.
Note that the initial value for the filter is still `FILTER_ID_ALL`,
so that in cases where (by accident) the call to `BKE_idtype_init()`
is omitted, semantically the situation is still correct. Not calling
this function is an easy to make oversight when writing unit tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/124357
Function `strip_data_outline_params_set()` was simplified, so setting
color and outline parameters are not mixed and overwriting as code flows
and so the function is better readable.
Shader code is changed, so that when strip overlaps other strip, it gets
2 px red outline regardless of whether it is active or selected. This
makes it more consistent when strip is not active or selected.
Pull Request: https://projects.blender.org/blender/blender/pulls/124442
Retiming was drawn for all strips in one draw call. During strip
transformation, if strips overlap, one strip should cover the other.
But all keys were drawn on top.
Retiming drawing API was changed to draw 1 strip, so overlapped strips
can be drawn first, followed by overlapping strips.
Since retiming drawing is also layered, single draw call was split into
drawing continuity line, keys and speed text.
Our icon sources currently include two versions of the Blender logo,
the official one and one that is modified to align better to our
smallest pixel grid. But with our recent change to SVG icons, and
alignment tweaks to the official version this can be used in all
cases. This PR does so, removes BLENDER_LARGE, and also slightly
tweaks FILE_BACKUP and FILE_BLEND to use the official form.
Pull Request: https://projects.blender.org/blender/blender/pulls/124179
The BLI_spin APIs use a `SpinLock` typedef whose underlying type is
contingent on the precense of `WITH_TBB`. Since our projects did not
consistently define the `WITH_TBB` definition, multiple `SpinLock` types
would end up in our final binary creating ODR violations.
Pull Request: https://projects.blender.org/blender/blender/pulls/124285
The `WITH_TBB` define needs to be set in order for code using the
various parallel threading helpers [1][2] to actually be multi-threaded.
The affected projects did not have `WITH_TBB` defined and were using the
single-thread variant of all affected APIs.
Additionally, in the case of `EnumerableThreadSpecific`, this results in
an ODR violation where there are 2 versions of the same class linked
into our final binary. One with TBB members and one without.
--------
[1] Namely code using the `BLI_task.hh`, `BLI_sort.hh`, and `BLI_enumerable_thread_specific.hh` headers
[2] `EnumerableThreadSpecific`, `parallel_for_each`, `parallel_reduce`, `parallel_invoke`, `isolate_task`, `parallel_sort`
Pull Request: https://projects.blender.org/blender/blender/pulls/124283
- Put them in the undo namespace, since they're quite tied to the undo system.
- Retrieve the nodes inside the functions, since they always need to act on
all leaf nodes conceptually anyway.
- Expose the position restore function publicly for use in the transform tool.
The lazy-function for a logical-or made the wrong assumption that
`try_get_input_data_ptr_or_request` returns null when `try_get_input_data_ptr`
returns null for the same input right before that. That's not true, because the
input might have been computed by another thread in the mean-time.
This wrong assumption lead to a bug because lazy-functions are always assumed to
either request more unavailable inputs, or compute all requested outputs. Here,
the lazy-function did neither. It wanted to request a new input, but it was
available already.
The solution is to handle the return value of
`try_get_input_data_ptr_or_request` properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124465
We generally do not want this struct to be copied due to its size. To
assist in finding development errors earlier, disable the copy
constructor entirely, as the destructor puts its resources into an
invalid state.
Pull Request: https://projects.blender.org/blender/blender/pulls/124439
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
This commit turns the base struct `uiItem` and all of its descendants
(including `uiButtonItem`, uiLayout`, etc.) into a C++ polymorphic
hierarchy of types.
This allows to use C++ type of memory management, and use non-trivial
types (which will be required to make `PointerRNA` non-trivial).
It also moves the storage of these `uiItems` from `BLI_listbase` to
`blender::Vector`, as our C-based listbase implementation is
incompatible with C++ polymorphism.
This also lead to making `uiItem` parameters of a few utils functions
`const`, to allow passing around `blender::Span` instead of vectors to
some internal helpers.
Pull Request: https://projects.blender.org/blender/blender/pulls/124405
`get_count_input_from_length()` did not check whether length is zero,
this would cause division by zero exception. Now will return a segment
count of 1 when a zero length is given.
Pull Request: https://projects.blender.org/blender/blender/pulls/124440
