The `Lineart` and `Opacity` modifier appear at the bottom of their respective
menus instead of following alphabetical order. There doesn't seem to be any
conceivable reason to do this, and it is inconsistent with how the modifiers
were laid out in older Blender versions. Fixes the order of the modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/130080
addon_utils.enable/disable now handle wheels so that the functions can
be used with extension add-ons.
A new argument `refresh_handled` supports scripts handing refresh
themselves which is needed to avoid refreshing many times in cases
when there are multiple calls to enable/disable.
This is mostly useful for internal operations.
Always use the Brush.color setting in the Draw mode side bar.
Technically the "Color" panel in the sidebar can draw in other modes,
but it's polling for explicit tools that limit it to the Draw mode
implicitly.
Use the appropriate brush or unified color in other GP modes based on
the unified paint settings flag.
Worth noting this was technically broken for a long time:
The default was that unified paint is disabled, so the GP panels would
use the brush color as expected. Enabling unified paint would then break
the colors, probably wasn't done very frequently since GP files
and e.g. mesh sculpting don't mix often. The default was changed in
#129127 to enable unified paint by default, which now breaks GP colors
by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/129790
Earlier in the brush assets project, for mesh sculpting, grease pencil,
and curves sculpting, the toolbar brush icon used was changed to a
version with a green highlight. This commit reverts that change to use
the monochrome grey icon instead in each of these modes.
For Sculpt mode specifically, the Paint tool icon is kept as this green
version to differentiate the usages. In future releases, further changes
are planned for sculpting related brushes to better represent their
functionality.
---
### Sculpt Mode Toolbar

Pull Request: https://projects.blender.org/blender/blender/pulls/129934
The label was hidden explicitly when saving changes wouldn't be
possible. But this was done for an earlier design iteration where there
would be a button to save changes, not just a label as indicator. The
indicator should always be shown when applicable.
Part of overall #118493 task: video input/output support at 10 and 12
bit/component formats. (note: this is still LDR videos just at higher
precision; there's no HDR handling (yet)).
Movie reading/playback: when movie file pixel format has >8 bit
components, decode those into a floating point ImBuf result. Previously
all movies were decoded into 8 bit/channel ImBufs, so 10- and 12-bit
movie pixel colors were getting quantized.
Movie output: when ffmpeg video with suitable codec is selected,
there's a color depth setting under Encoding block. Currently that is:
- 10 bit option for H.264, H.265, AV1 (VP9 could do 10 bit in theory too,
but ffmpeg that is built in Blender does not have that compiled in)
- 12 bit option for H.265, AV1
When "lossless" is picked, then similar to how for regular 8-bit video
it switches from YUV 4:2:0 to 4:4:4, this also switches to 4:4:4
10- or 12-bit variant.
Pull Request: https://projects.blender.org/blender/blender/pulls/129298
When doing action baking, the option "Clear Constraints" mentions
it's doing visual keying while not actually using that option.
Just fixing the description, even though a better solution
would be to revisit the design of the options to see if they
even make sense in some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/129052
Vulkan backend selection will be hidden behind developer extras. There
are some issues which would not be inviting for users to start testing.
- Some basic functionality are not working (object selection, depth
testing)
- NVIDIA UI artifacts are annoying and unsure where the error is.
- AMD artifacts
- Memory leaks
The backend will still be part of Blender 4.3 only hidden behind an
additional flag.
Ref: #129265, #129262, #127225, #128624, #127768, #127223
Pull Request: https://projects.blender.org/blender/blender/pulls/129799
Accidentally added in d70b10dcd4 and moved in dc652aeedb, the
`GREASE_PENCIL_OT_stroke_trim` operator is meant for usage in draw mode
(as the Cutter tool), but not in editmode. It is not the same as the
GPv2 Trim operator, see 4fbef3dc6b
To resolve, remove this from the menu again.
Pull Request: https://projects.blender.org/blender/blender/pulls/129805
Replace plain-text type information with the type syntax used
for Python's type annotations as it's more concise, especially for
callbacks which often didn't include useful type information.
Note that this change only applies to inline doc-strings,
generated doc-strings from RNA need to be updated separately.
Details:
- Many minor corrections were made when "list" was incorrectly used
instead of "sequence".
- Some type information wasn't defined in the doc-strings and has been
added.
- Verbose type info would benefit from support for type aliases.
With the brush assets project, many paint tools are no longer specified
by tool. To maintain functionality, this commit inspects the brush type
instead of hardcoding against the paint tool to ensure that no matter
which tool is being used, the UI displays correctly based on the brush.
Pull Request: https://projects.blender.org/blender/blender/pulls/129654
For now, PointerRNA is made non-trivial by giving explicit default
values to its members.
Besides of BPY python binding code, the change is relatively trivial.
The main change (besides the creation/deletion part) is the replacement
of `memset` by zero-initialized assignment (using `{}`).
makesrna required changes are quite small too.
The big piece of this PR is the refactor of the BPY RNA code.
It essentially brings back allocation and deletion of the BPy_StructRNA,
BPy_Pointer etc. python objects into 'cannonical process', using `__new__`,
and `__init__` callbacks (and there matching CAPI functions).
Existing code was doing very low-level manipulations to create these
data, which is not really easy to understand, and AFAICT incompatible
with handling C++ data that needs to be constructed and destructed.
Unfortunately, similar change in destruction code (using `__del__` and
matching `tp_finalize` CAPI callback) is not possible, because of technical
low-level implementation details in CPython (see [1] for details).
`std::optional` pointer management is used to encapsulate PointerRNA
data. This allows to keep control on _when_ actual RNA creation is done,
and to have a safe destruction in `tp_dealloc` callbacks.
Note that a critical change in Blender's Python API will be that classes
inherinting from `bpy_struct` etc. will now have to properly call the
base class `__new__` and/or `__init__`if they define them.
Implements #122431.
[1] https://discuss.python.org/t/cpython-usage-of-tp-finalize-in-c-defined-static-types-with-no-custom-tp-dealloc/64100
This operator deals specifically with add-ons, using the term extensions
is misleading as it works for legacy (non-extension) add-ons and
extensions can also be themes.