Move the versioning code that switches the Timeline editor to Dope
Sheet from the 'first' to the 'after linking' versioning stage.
There was already versioning code that effectively turns the Dope
Sheet back into a Timeline, for pre-2.80 files, and this runs in the
'after linking' stage. The 5.0 versioning code now correctly runs
after this.
Fixes: #147742
Pull Request: https://projects.blender.org/blender/blender/pulls/147734
Only draw the Summary backdrop color when the Summary channel has been
expanded. This prevents the default used-to-be-timeline Dope Sheet
from showing a big red bar at the bottom of the window.
The channel box backdrop (when the channel bar is expanded) also
follows this, so when expanded it is red as before, and when collapsed
it is dark grey.
Pull Request: https://projects.blender.org/blender/blender/pulls/147708
Blender cannot handle bones with (near) zero length. Prior to this
commit such bones were deleted when exiting Armature Edit mode. Now
they are kept and elongated so that they are numerically stable (or at
least they should be, given the threshold to the length that was
already in place).
To avoid the elongation from impacting the position of child bones,
they are disconnected from the tiny bone.
Apart from that it's quite nice for users that Blender no longer
silently deletes bones, this is also useful for the USD importer, as
it can import bones and expect them to exist afterwards (see
#147048).
Note: this only impacts armatures with bones of length ≤ 0.000001
units.
Pull Request: https://projects.blender.org/blender/blender/pulls/147814
Add a command line option to load Blender without a window frame.
Currently this is only used on Wayland, enabled for WITH_UI_TESTS since
attempting to load LIBDECOR caused the tests to crash on start on Fedora.
For tests there is no need to use LIBDECOR, so disable the window frame.
This can also be used by users who don't want to use the X11 fallback if
LIBDECOR can't be found.
Ref !147716
Only draw the Summary backdrop color when the Summary channel has been
expanded. This prevents the default used-to-be-timeline Dope Sheet
from showing a big red bar at the bottom of the window.
The channel box backdrop (when the channel bar is expanded) also
follows this, so when expanded it is red as before, and when collapsed
it is dark grey.
Pull Request: https://projects.blender.org/blender/blender/pulls/147708
Rename modules in `./scripts/modules/` to use an underscore prefix to
make it clear they aren't intended to be part of public API's. This
also means there is no implication that these modules should be stable,
allowing us to change them based on Blender's internal usage.
The following modules have been marked as private:
- `animsys_refactor`
- `bl_console_utils`
- `bl_i18n_utils`
- `bl_previews_utils`
- `bl_rna_utils`
- `bl_text_utils`
- `bl_ui_utils`
- `bpy_restrict_state`
- `console_python`
- `console_shell`
- `graphviz_export`
- `keyingsets_utils`
- `rna_info`
- `rna_manual_reference`
- `rna_xml`
Note that we could further re-arrange these modules
(under `_bpy_internal` in some cases), this change is mainly to mark
them as private, further changes can be handed on a case-by-case basis.
Ref !147773
Since VSE HDR preview was implemented (18110744a2), the preview image
is put into RGBA 16F format "color texture", and the overlay
(checkerboard, grids etc.) is put into RGBA 8U format "overlay texture".
This was rendering the color image as NON premultiplied alpha in
the viewport color texture, which is not what happens in other places
(e.g. image space).
Later commit (c279d894db) fixed transparency of the overlay texture,
in order to make pure emissive (color non zero, alpha zero) colors
from EXR files show up in VSE preview. However that exposed the issue
that underlying color texture is not premultiplied.
Fix this by premultiplying the output color in gpu_shader_display_transform
that is used by VSE preview. This is done at the end of the shader
isntead of using fixed function blending, since premultiplication needs
to happen in a way that preserves pure-emissive colors.
Comparison images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/147892
We have icons that represent specific individual collections. like
Icon_Outliner_Collection for a default (uncolored) collection, and
Icon_Collection_color_x for ones with colors. For "collections" as a
general thing though we have icon_group. Sometimes we confuse the two,
for example the list of tabs to show in Properties uses a different
icon than the actual category icon. This PR fixes the complaint by
using the correct icon for each of these purposes.
Pull Request: https://projects.blender.org/blender/blender/pulls/147942
The previous commit 80e8493c11 was incorrect. I must have
tested it incorrectly, because `BLI_path_contains` only tests the
beginning of the path. Instead just make the shorter asset path
native, and explicitly use StringRef for the test.
The RNA property had an incorrect update callback assigned. The
update callback assumed the RNA pointer data was a node rather
than a node's viewer item.
I think the special handling for string input node, added in #139478,
was broken by #146033. The early check for src_value (`if (!src_value)`)
caused the string-specific logic to be skipped. This PR moves the
string-specific handling before the src_value check.
Pull Request: https://projects.blender.org/blender/blender/pulls/147697
Snap translation to the world grid when absolute grid increments is
enabled. Previously, absolute increment snap shifted in perspective
view, causing objects to misaligned with the world grid.
Resolves regression introduced since 3.6.
Ref !147246
Resolve regression in [0] which hid transform overlay in the image view.
The indicator now displays when overlays are enabled in the UV editor.
[0]: 1df4a09539
The flag that skips objects for snapping (`BA_SNAP_FIX_DEPS_FIASCO`) is
set for all objects that have a `DEG_OB_COMP_TRANSFORM` relation.
However, when the **Affect Only Parent** option is enabled, children
are not transformed and therefore could still be snapped to.
Despite this, the `DEG_OB_COMP_TRANSFORM` dependency remains present on
them.
To address this, a new callback was introduced that skips
Transform-to-Transform dependencies while preserving
Transform-to-Geometry dependencies in this scenario.
This approach may introduce some false positives, leading to spurious
dependency cycles (e.g., when constraints are involved).
Nevertheless, the trade-off favors accepting these false positives
rather than disabling the feature altogether.
Also make non-functional change that just removes a flag before the snap
loop, thus avoiding checking if the flag exists inside the loop.
Ref !142007
There was a bug in the move_weld_profile_planes function where
it would only move the profile plane involved in a "weld" if
certain vectors were not too small (less than BEVEL_EPSILON in
length). The intent of the code was just to avoid problems with
zero length normals (post normalization), and the normalize_v3
function indicates that with an exact 0.0f return, so there was
no need for an epsilon test.
The example file in the issue had a small-scale model (100 times
smaller than typical), which ended up causing the old code to
prevent moving the profile plane to where it belongs.
Pull Request: https://projects.blender.org/blender/blender/pulls/147898
Disabling (at least temporarily) the fading animations shown during and
after some area maintenance routines (like splitting, joining, closing)
as this causes memory leaks during automated testing. This doesn't
occur during regular usage, just when the window is closed within the
animation time. We'll look for an improved solution in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/147890
Moving `__call__` logic into Python's C-API means error messages
caused by operators reference the code of the caller instead of the
call from `.scripts/modules/bpy/ops.py`.
When a full call stack is available this isn't so important,
however when logging callers it's not useful to log the call
from `ops.py`.
There minor performance advantages for moving from Python to C++
however this wasn't a significant consideration for the change.
Note that this is a fairly direct conversion from Python to C++,
there is room for refactoring to simplify the calling logic.
See #144746 for the motivation & #147448 for further improvements.
Ref !145344
