When (de)selecting the active material, use the active slot
falling back to the first-used slot (for non-active objects).
Resolve regression in [0].
Ref !125948
[0]: 296d05060d
Part of #118145.
- Specialize the algorithm for each geometry type.
- Store the cache in an array instead of an attribute. Attributes are
meant to store user-edited data, not derived data like caches.
- Calculate the island IDs with a parallel disjoint set instead of a
flood-fill algorithm.
- Avoid storing the island ID array if there is only one island, saving
1 byte per vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/125907
The RNA path that is generated for Editor properties were mostly
incomplete (e.g. the viewport overlay settings).
- in python tooltips
- from the `Copy (Full) Data Path` operator
- python methods `path_from_id`, `path_resolve` returned incomplete paths
Since a space (editor) is ultimately owned by the screen, we now add the
missing "areas[x].spaces[x]" subpath to any editor.
Nested structs (like the viewport overlay) also need to include this
subpath.
Some editor related structs are not tied to a single space though (and
these cases are therefor not resolved yet):
- Dopesheet is referenced from SpaceGraph, SpaceAction and SpaceNla
- View3DShading is referenced from SpaceView3D but render engines as
well
- FileSelectParams / FileAssetSelectParams / FileAssetSelectIDFilter
need more investigation
NOTE: in case of the VSE, to make this work this also changes the
overlays to be tied to SpaceSeq (the only editor using them)
NOTE: since the above is now in place, adding VSE overlay props to Quick
favourites is now made possible as well (was a leftover from !116604)
Fixes#124527, #113489
Pull Request: https://projects.blender.org/blender/blender/pulls/125365
Together with changes from upstream audaspace, this should fix the
issue. The change slightly increases the duration of the scrubbing
sound to ensure that the audio buffer size gets played back at least
before it stops playback.
The File Output node doesn't provide an option to save byte formats like
PNG in a space that is not sRGB. This is problematic for data images
like normal maps, which need to be saved as non-color.
This patch adds a Color Space option to the File Output node to allows
users to override the assumed color space. This also adds a new global
Save As Render option that is used if Use Node Format is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124238
PR #125332 made changes to the format of the version string displayed
on the title bar and in status bar. These changes included not showing
the patch level if zero. Unfortunately this also changes the version
as displayed on the command-line with "--version". This particular
change was approved quite hastily so this PR just reverses that, always
shows zero patch level and therefore shows the command-line version as
before. If we want to hide patch zero we can debate this specifically
later.
Pull Request: https://projects.blender.org/blender/blender/pulls/125788
Part of #118145.
Instead of storing a separately allocated array for each BVH node
for the temporary "color buffer" colors meant for mixing during a
stroke, just store an array the size of the whole mesh. Though this
is wasteful in terms of memory usage, plenty of other brushes store
mesh-sized arrays already, and it should make more sense as BVH
nodes get smaller too. After this commit, the BVH tree has no
specific code for color attributes anymore.
This tries to keep to the spirit of task of #124511. Title bar shows
a more detailed version string, while status bar shows more compactly.
"LTS" is included in the long form when defined. Patch version shown
in both detailed and long form but only if non-zero. "Alpha", "Beta",
"Release Candidate" included in long form, but uses " a", " b", " RC"
for short form.
Pull Request: https://projects.blender.org/blender/blender/pulls/125332
`BLO_read_data_address` should basically almost never be used. However,
this code is not trivial to update, and it has an active team working on
it, so for now just tagging the issue there.
These type of non-owning pointers to other internal data (often used for
'active data') should not use 'refcounting' BLO API, but instead merely
retrieve the new address without marking it as used.
That address is supposed to be part of read data when processing the
actual storage, marking it as used by non-owning pointers is logically
wrong and _could_ potentially hide actual bugs in reading code.
All of these changes should be trivial, like using `string` read/write
code for strings, and a convert a few usages of 'raw data' read/write
calls to the 'struct' ones.
No behavioral changes expected here.
EEVEE writes wrong Cryptomatte meta data layer name. The view layer name
is always prepended to the Cryptomatte layer name, which can cause the
view layer name to be duplicated or the existence of view layer name
where it shouldn't be.
Old: cryptomatte/{hash}/name: string 'ViewLayer.ViewLayer.CryptoObject'
New: cryptomatte/{hash}/name: string 'ViewLayer.CryptoObject'
Pull Request: https://projects.blender.org/blender/blender/pulls/125515
Loading GPv2 files was crashing after modifiers were removed in #125102.
The modifier type info structs were still used for some internal
purposes (`struct_name`, `free_data`, `foreach_ID_link`), but the info
was not registered any more.
Since we only need a small portion of the typeinfo and because GPv2
modifiers will never change, using simple functions with switch
statements makes more sense here than bringing back fully fledged
typeinfo struct registration.
Pull Request: https://projects.blender.org/blender/blender/pulls/125663
There was already code to handle active scene pointer for the window.
Simply replace it by a call to `wm_data_consistency_ensure`, which will
ensure that all potentially missing pointers in UI data get reset.
This adds a `geometry::smooth_curve_positions` function that
smoothes both bézier curves and all the other curve types.
Bézier curves are smoothed by joining the handle and control
points into a flat array, then using the 1D gaussian algorithm
and writing the resulting positions back into the left and right
handle positions as well as the control points. In general,
this works reasonably well and is similar to the results of the
other curve types.
Pull Request: https://projects.blender.org/blender/blender/pulls/125496
Previously, it was not possible to see detailed information about instances in
the spreadsheet. Only the attributes on the top level instances were shown. Now,
all nested instances can be inspected too.
Combined with #114910 this will make inspecting more complex geometry with the
spreadsheet much more feasible. It's also an important part of integrating
grease pencil into geometry nodes because it makes it more obvious how layers
are converted to curve instances.
The data-selection is split into two separate tree views now. One that selects
the geometry from the instance tree, and one that's used to select the geometry
component and domain within that geometry. We found that this works better than
combining both tree views into one (we tried that in #124186).
Pull Request: https://projects.blender.org/blender/blender/pulls/125293
This removes the legacy Grease Pencil modifiers from the code.
These should have already been inaccessible from the UI and hidden from
the user. The modifiers have been reimplemented for the new GPv3
data structure.
On top of the modifier code, some other related things have been
removed as well:
* Operators related to the legacy modifiers.
* Keymaps for the legacy modifier operators.
* Some bits of code that used modifier functions.
Some code has to be kept, because it is still used:
* The core line art code, which is used by the new line art modifier. It's
moved to `modifiers/lineart`.
* The DNA structs for the legacy modifiers. They are still needed for
conversion.
* A few kernel functions for the modifiers are kept (also for conversion).
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/125102
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
Introduced with d527e3a6bd.
Cached values are tagged as dirty during the update step, this can cause
conflicts where we attempt to then flush then changes into the PBVH but
have not yet updated the mesh pointers and reinitialized them.
This commit forcibly initializes the underlying data to prevent such
cases from happening when flushing to the PBVH.
Pull Request: https://projects.blender.org/blender/blender/pulls/125396
This is a PR that is built on top of #122094 (thanks to @SietseB
for the initial work).
Adds the following properties and functions:
* `layer.frames`,
* `layer.frames.new(frame_number)`
* `layer.frames.remove(frame_number)`
* `layer.frames.copy(from, to)`
* `frame = layer.get_frame_at(frame_number)`
* `frame.drawing`
* `frame.frame_number`
* `frame.select`: the selection state of the keyframe in the dope sheet
* `frame.keyframe_type`
* `drawing = frame.drawing`
* `drawing.type` (`DRAWING`/`REFERENCE`)
* `drawing.user_count`: The number of keyframes that use this drawing
* `drawing.attributes`: attribute read/write access to the drawing data
To be able to access attributes on drawings, a new
`AttributeOwnerType::GreasePencilDrawing` is added.
The API in `BKE_attributes.h` is updated to handle this type.
In `rna_attributes.cc`, there is a new
`rna_def_attribute_group_grease_pencil_drawing` that defines the
attribute group. For this to work, it also defines its own rna
callback functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/124787
This was just rather useless level of abstraction. I heard from other
devs that these helper classes caused confusion, so better to avoid
this.
Now the asset representation has all the needed bits to create its full
path, blend-file path and asset library relative path. In fact only the
asset library relative path needs to be stored to make all this
available, since the asset representation already stores a reference to
the asset library owning it, so the paths can be recreated easily.
When writing a layered Action to disk, take the F-Curves from the
first keyframe strip and write that as `action.curves` as well. This
will make older Blender versions see those curves and load them
properly.
Only the curves for the first slot are written this way. This means
that any legacy Action that was converted to a layered Action will be
loaded again properly by older Blender versions. Of course this is
limited to a single layer, single strip, and single slot -- once the
newer features are used, older versions of Blender will not be able to
see this extra data.
When an Action contains multiple slots, so with animation for multiple
distinct objects, the forward compatibility becomes a bit iffy. Older
versions of Blender will just see a legacy Action, with its legacy
semantics, and thus all objects that use that Action will receive the
exact same animation data. I don't think there's a way around this.
(_Unless we start breaking up Actions into an Action per slot, alter
the assignments, and then store metadata so that modern Blenders can
reassemble them. I do not think this is a good idea._)
Ref: #124714
Pull Request: https://projects.blender.org/blender/blender/pulls/125065
