Caused by #143974.
Allow `use_sequence_detection` and `use_placeholders` to be
automatically drawn by `sequencer_add_draw_check_fn` when applicable
instead of unconditionally adding it to the UI.
Ordering of these two can be preserved by swapping the original
`RNA_def_boolean` calls.
Pull Request: https://projects.blender.org/blender/blender/pulls/145431
This commit changes the internal storage and user-facing representation
of the brush size values (`size` and `unprojected_size`) from radius
to diameter.
This has a number of benefits:
* While the radius is more helpful for many internal operations, it is
more natural to estimate the size of a brush by the diameter
* Because the pixel size is stored as an integer, users are currently
unable to make brushes that have an odd numbered diameter, notably
preventing the ability to make single pixel brushes.
Internally, the `Brush` and `UnifiedPaintSettings` size values are
versioned to double their on-disk values. The relevant `BKE` functions
that access the data return the radius at runtime, and any internal
`struct`s that stored radius continue to do so.
The 'Radius' text for brushes is changed to 'Size' and all references
to it in descriptions are changed to 'size' as well.
Resolves#134204
Pull Request: https://projects.blender.org/blender/blender/pulls/142495
Continuing #140360
This PR moves keyframe theme properties from editors into Common.
Besides Dope Sheet, keyframe properties were in:
- Sequencer (almost all types, and might use more in the future)
- 3D Viewport, where the active object name overlay used a separate Object Keyframe color when
it had keyframes on the current frame. Now it uses the common Keyframe Selected color, instead
of having its own property just for this little text.
- Keyframes in Movie Clip Editor were hard-coded white, now they use a common Keyframe color.
Selected colors used wrong long key selected color, now they use common Keyframe Selected color.
- Movie Clip Editor also used separate colors for what it called "Strips", but they are visually
the exact same thing as "long keys" in Dope Sheet, so they use common long key colors now.
There are Keyframe Border properties in Dope Sheet, Sequencer, and NLA, but they're not shared
because they're drawn on very different backgrounds, in different sizes, with different fill colors, so
it's difficult to make one color work for all of them, and it can restrict customization and accessibility.
Video in PR
---
Details:
- Long keys in Dope Sheet/Clip Editor and Strips in NLA used the same internal "strip" attribute.
Those needed to be separated to properly use long key colors in common, without worrying
about affecting unrelated things, and those two are as unrelated as they can get.
To properly separate them I added new "long_key" attributes, and corresponding
`TH_LONGKEY` and `TH_LONGKEY_SELECT`.
- Long keys in Movie Clip Editor had hardcoded alpha. Now they use alpha of the theme color.
Pull Request: https://projects.blender.org/blender/blender/pulls/144259
This commit changes the face_ptex_offset from a manually managed int
array to a blender::Array. This required a number of changes:
* The `Subdiv` struct is no longer trivial, so MEM_new and MEM_delete
need to be used
* The Draw module API has an overloaded set of `origindex_buffer`
methods created to take in a Span instead of an int pointer and size
Pull Request: https://projects.blender.org/blender/blender/pulls/141702
In RNA access code, when trying to 'decode' a given property into valid
data, if the existing storage IDProperty for a runtime-defined RNA
property was detected as invalid (e.g. wrong dimensions for an
array...), code was trying to remove that property from the user-defined
IDProperties (custom properties) instead of the system ones.
Mistake from the original IDProperty split commit (7276b2009a).
Don't init duplis if `dupli_list` is empty.
Otherwise, the `data->dupli_parent` "leaks" into the next objects.
This also asserts that dupli iteration properties are set to default
values when calling `deg_iterator_duplis_init`.
Pull Request: https://projects.blender.org/blender/blender/pulls/145407
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. I'm working on the pointer stability
solution now to address a memfile undo performance regression
in 5.0 due to the `AttributeStorage` read/write design.
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.
This change is backward compatible but not forward compatible.
Second try after #144626
Pull Request: https://projects.blender.org/blender/blender/pulls/144878
When copying grease pencil strokes, `BKE_object_material_get()` was used
to retrieve the material ID, but the index starts at 1 instead of 0,
this caused the pasted material to be wrong. Now the index is properly
incremented to 1 when copying.
Pull Request: https://projects.blender.org/blender/blender/pulls/145398
The pose library registered a double-click keymap item for the file
browser keymap, because that was the only way to add keymap items to the
asset browser (which is just the file browser under the hood). Since
450f428434, the pose library apply & blend operators are available in
more contexts, since their check for an active asset was moved from the
operator poll to the operator execution. So the pose apply operator
would end up triggering.
The poll function could be adjusted somehow to return false in this
case, e.g. by checking if it's executed from a file browser (not an
asset browser).
However, the operator should be independent of where it's called from.
So instead this registers a separate keymap for the asset browser, so
the pose library operators can be registered exclusively for the asset
browser.
Moves the descriptor pools from resource pools to thread data.
The descriptor pools uses a recycling approach and don't need
to be guarded anymore inside a resource pool. Now only the
descriptor set tracker is inside the resource pool.
Pull Request: https://projects.blender.org/blender/blender/pulls/145393
Previously `SVGExporter::export_scene` can work on a empty `frames`
index mask, causing crash. Now it will exit early when no frames are
selected, and it will show a warning to the user.
Pull Request: https://projects.blender.org/blender/blender/pulls/145286
The outliner was still using the active scene to show the sequencer
strips in the VSE mode.
This adds the workspace to the `TreeSourceData` so that
the `TreeDisplaySequencer` can read the sequencer
scene.
Note that more places need to be fixed to make this mode
work correctly again.
Pull Request: https://projects.blender.org/blender/blender/pulls/145247
This commit refactors the relevant code to extract the
logic of determining which cache to use into a centralized location to
avoid missing updates happening in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/143580
Added in 8d6c717e34
These enums are unrelated to nodes. The fact that nodes reuse the
enum property items is an implementation detail that shouldn't leak.
Currently it causes the type dropdown in the "Add Attribute" operator
to be full of node socket icons.
At a data level it is also not clear that these should have node socket
colors, even in geometry nodes. Arguably it's important to distinguish
between attribute types and socket types, especially since some
attribute types cannot be explicitly passed around by node links.
For now, revert the parts of that commit that added node socket icons
in areas unrelated to the node editor. If we're going to do that it needs
proper consensus and a more complete design.
The pattern of transforming many position vectors at once is quite
common, both with separate source and result arrays, and when modifying
an array in place. In some cases at least we used a separate function
with a consistent name across files, but there were also many duplicate
parallel transform implementations.
This commit adds these utilities to the BLI_math_matrix.hh API and uses
them where many positions from contiguous arrays are transformed at
once. While there might be a more ideal location for these utilities,
it's consistent with 3936d7a93e, and certainly better
than duplicating them.
This also reduces binary size of my build by 15 KB.
Pull Request: https://projects.blender.org/blender/blender/pulls/145352
Selected tracks in the Movie Clip Editor's Dope Sheet used hard-coded color.
Added a new theme property for them, and previously hard-coded color is now just a default.
Pull Request: https://projects.blender.org/blender/blender/pulls/144265
While handling this pointer is technically not needed in `foreach_id`
code (and likely never will be), better not rely on such undocumented
implicit specifics, and instead properly handle it there, with comments
and asserts explaining why it should not be actually executed in current
code.
Pull Request: https://projects.blender.org/blender/blender/pulls/145345
When line art is first developed, curves objects does not exist yet, now
it is added to line art so it will be read and take part in feature line
generation and occlusion tests.
This patch also adds "Line Art" panel for curves object, just like other
objects supported by line art.
Pull Request: https://projects.blender.org/blender/blender/pulls/145296
The PR restores the old behavior (after the changes in #139128) so that
specifying a path to a non-existing blend file will load Blender with
default blend default and with that name assigned. Paths to non-blend
files will load blender but then give the new warning message.
Pull Request: https://projects.blender.org/blender/blender/pulls/145274
This adds support for opening "invalid" files containing closure/bundle nodes that have
first been saved with 5.0, then resaved with 4.5. Note that loading them in 4.5 only works
after #145337.
Pull Request: https://projects.blender.org/blender/blender/pulls/145333
This patch optimizes nodes with Boolean and Menu inputs for GPU
execution. This is done by using constant links instead of uniforms for
those inputs. This will cause shader recompilation, but is okay since
those inputs rarely change.
Pull Request: https://projects.blender.org/blender/blender/pulls/145329
Caused by d7fa455e66
Due to an earlier experiment to get right alignment, above commit left a
space in the text (this was later solved by using
`UI_ITEM_R_SPLIT_EMPTY_NAME`, but... for this one node, the name was not
actually empty then...)
Pull Request: https://projects.blender.org/blender/blender/pulls/145303
The function was using the `BKE_id_material_len_p` with the ID
of the object rather than the object data ID, which is what the
function expects.
Instead make sure to use `BKE_object_material_len_p` to get
the right number of material slots.
Additionally use the correct slot in `BKE_object_material_get`
which is the index of the material + 1.
Pull Request: https://projects.blender.org/blender/blender/pulls/145323
Previously, `VArrayImpl` had a `materialize` and `materialize_to_uninitialized`
function. Now both are merged into one with an additional `bool
dst_is_uninitialized` parameter. The same is done for the
`materialize_compressed` method as all as `GVArrayImpl`.
While this kind of merging is typically not ideal, it reduces the binary size by
~200kb while being basically free performance wise. The cost of this predictable
boolean check is expected to be negligible even if only very few indices are
materialized. Additionally, in most cases, this parameter does not even have to
be checked, because for trivial types it does not matter if the destination
array is already initialized or not when overwriting it.
It saves this much memory, because there are quite a few implementations being
generated with e.g. `VArray::from_func` and a lot of code was duplicated for
each instantiation.
This changes only the actual `(G)VArrayImpl`, but not the `VArray` and `GVArray`
API which is typically used to work with virtual arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/145144
