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
Part of #118145.
The proxy system was used to store the accumulated translation from
the deformation of multiple symmetry passes. After a brush/tool update
step, all PBVH nodes with proxies were gathered, the proxies from
each symmetry passes were accumulated, and the deformation was applied
to the evaluated mesh, then the base mesh and shape keys.
In the recently refactored brushes, the translations are immediately
applied to the base mesh and shape keys instead. That avoids the need
for storing a float vector for every affected vertex during the
deformation. Reducing memory usage and affecting the memory that is
already hot in the cache has significant performance benefits too.
Also, brushes are now more conceptually independent-- they don't
rely on a separate pass to actually apply deformations.
Finally removing the proxy system reduces the size of PBVH nodes from
728 to 416 bytes. That's helpful as part of the effort to reduce per-
node overhead in order to make nodes smaller, and helps to reduce the
responsibilities of the PBVH, to focus it on being a BVH tree instead
of "bag for storing arbitrary user-interaction data."
Move the node update tagging and normal recalculation outside of the
generic filter initialization to the callers. This avoids unnecessarily
recalculating all normals when the filter/transform starts. That's
especially unnecessary for the color filter which doesn't affect positions.
Part of #118145.
There is more cleanup possible here, particularly doing some loop
fission and making the brush use our common utilities will help
remove some code and make better use of auto-vectorization.
But with this commit the code we want to remove is no longer
used, so we can stop here for now.
Size icons to subpixel precision to give slightly better results when used
with fractional resolution scales.
---
This change is very subtle. So you might have to trust me or get your reading glasses on...
Our icons are designed for small sizes. When the Blender resolution scale is set to exactly 1.0 then the icons are aligned perfectly to a 14x14 grid and features like lines are exactly one pixel wide. So these one-pixel wide lines are perfectly aligned to the pixel grid. Change the scale to 2.0x and they also align perfectly, just with lines that are two pixels wide.
But what happens at 1.25x scale? Now the icon is 17.5 pixels and lines in it are a pixel and a quarter wide . The best that can be is a solid pixel and one next to it that is quarter-opacity. But it can get worse than that as it could potentially touch three adjacent pixels.
Our old icon code took an icon bitmap that was rendered larger and scaled it into the desired size. Because this was done by the opengl shader, this scaling was done to subpixel size. So at 1.25 scale you got an icon that was 17.5 pixels.
The new icon code is truncating the sizes to integer before rendering. I thought this was best, but I was wrong.
The following image has three rows. The top is the old icon code, with UI scale from 1.0, 1.25, 1.5, 1.75, and 2.0. The second row is current code. The third is with this PR:
The first and last columns are identical, obviously because the design perfectly fits the pixel grid.
The left green area, at 1.25 scale, current code is forcing the design into an integer size, while (bottom) gives a more pleasing result as it is properly spread over 17.5 pixels.
The right green area is more interesting. With both the old code and new code, the 1.75 pixel wide line is spread over three pixels. The PR nicely spreads it over two pixels.
Hard to tell; Just squint. This is just very slightly more pleasing rendering of icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/124436
Moving a strip retiming key at the end of a strip, so that a strip
overlaps another one would leave them overlapped. The expected
behavior is that it acts according to the Overlap Mode, like it does
when moving a strip.
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/124424
Lowering the speed of a strip that doesn't have user-created retiming
keys using the "Set Speed" operator would cause the strip to overlap
neighboring strips. The fix shuffles the retimed strip to avoid
overlap. This now matches the behavior of the same operator, when
using it on a user created retiming key.
Pull Request: https://projects.blender.org/blender/blender/pulls/124414
