ED_area_newspace correctly changes an area's space when the type and
subtype are set beforehand. But SCREEN_OT_space_type_set_or_cycle, when
changing to a new editor rather than cycling, needs newspace to ignore
the set subtype and use the last-used saved in the space. This
situation cannot be tested for in newspace. Instead have the operator
pass -1 as subtype to signal this intended behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135367
The line-width is used to calculate the `U.pixelsize` which should only
be used to control the size of lines & points.
Update doc-strings to mention the intended use, remove unused defines.
This is due to accessing member of nullptr Asset. After deleting the
action id from asset library, `CTX_wm_asset` won't return value because
force reset for files was tagged (`FL_FORCE_RESET_MAIN_FILES`).
Instead of updating library from active asset, use library reference to
clear then read/draw the updated asset library
Pull Request: https://projects.blender.org/blender/blender/pulls/135219
Patch #132957 added helpful UI feedback when attempting to rotate or
scale an object whose transforms are set to "only affect locations."
But it neglected to check for invalid trackpad rotations that are
affected the same way. This patch renames the original `HLP_ERROR` to
`HLP_ERROR_DASH` to distinguish it from a `HLP_ERROR` transform cursor
with no dashed line present, which matches trackball's normal state.
Pull Request: https://projects.blender.org/blender/blender/pulls/134653
While joining and docking areas there is hint shown near the mouse that
describes the potential operation. But it is cut off if your mouse is
at the extreme right or bottom edge of the window. This PR just clamps
the position so it is always visible.
Co-authored-by: Jonas Holzman <jonas@holzman.fr>
Pull Request: https://projects.blender.org/blender/blender/pulls/135211
The operator refused to pack libraries with absolute paths (wasnt the
case in its original implementation 16411da41e, but was added in
129fb516f4 -- for the reason of preventing "bad things happen on
unpacking" without an explanation of what these exactly are). It did so
by cancelling as soon as **one** library with ab absolute path was
found.
Now with the introduction of essential assets, we have those absolute
path linkages more or less "by default" as soon as e.g. a brush is
used, so the operator is more or less unusable now. NOTE: these absolute
essential asset library paths seem to be converted to relative on save?
Upon reload, these are then gone... (might be another hint for an
alternative fix, see below)
By "bad things happen on unpacking" I would assume the scenario of
folders being created in unwanted locations (e.g. when moving from one
OS to another), but the same thing is also true for packing **files**
instead of libraries (there, absolute paths are allowed, and unpacking
in original locations can equally fail or create folder structures that
are "unexpected"). NOTE: for files though we have the choice of
unpacking to a relative folder (which wouldnt really be possible since
libraries can be nested and we would have to correct paths all over the
place). NOTE: the chance of creating "unwanted" folder structures with
relative paths might be slimmer, but if you have a lot of "upwards"
parent folders, relative can easily "break" as well.
Possible ways to resolve this:
### [1] skip libraries identified as essentials assets (still cancel on all other absolute paths)
Can check a library path to be contained in `EssentialsAssetLibrary`
`essentials_directory_path`. This would be the safest imo since it is a no-behavior change.
### [2] lift the limitation of absolute paths alltogether
Like mentioned above, things could break with "relative" almost as
easily as with "absolute", there might even be scenarios where
"absolute" is wanted. It is a more behavior-changing fix that we might
explore more after 4.4 is out.
### [3] skip absolute libraries (but continue with non-absolute libraries)
This does change behavior as well (it does not cancel as soon as **one**
library with ab absolute path was found anymore, but the worst case
scenario is that you end up with an "incomplete" file if you really
mixed absolute and realtive lib linking).
This PR implements [1] for now, [2] or [3] can follow for 4.5.
Fixes#134665
Pull Request: https://projects.blender.org/blender/blender/pulls/134839
`ColorManagedDisplaySettings`, `ColorManagedViewSettings`,
`ColorManagedInputColorspaceSettings` were affected since these are used
from multiple places (Scene, File output nodes, ..).
Similar to how we are getting the path for `ImageFormatSettings` (which
pretty much has the distinction logic already), we can do so for the
ColorManage Settings as well (piggbacking on the already correct path to
the `ImageFormatSettings`.
With this, we can also remove these "known failures" from the test
introduced in 4032b853c3.
Pull Request: https://projects.blender.org/blender/blender/pulls/135238
Volumes' "Sequence Mode" recently got the "Sequence" context in
2b3f0d0110. The intention was to disambiguate the "Extend" enum item,
but this caused another item, "Clip" to also get this context. That
one already existed and referred to a sequencer clip.
Use the more specific "Volume" context instead.
Reported by Gabriel Gazzán.
OpenEXR DWA compression in Blender is derived from a more user-friendly
quality slider which has an intuitive range 0 .. 100.
Initially the mapping was done so that the visually lossless JPEG
quality of 97 was mapped to the default DWA compression 45. A point was
made that we should make it so default quality is mapped to the default
compression, following the intent of DWA for rendering and compositing
the main target.
This change adjusts the mapping so that quality of 90 is mapped to DWA
compression 45.
This change relies on the library update to fully utilize the DWA
compression #135037.
This change leads to the difference in the way proxies of EXR images
are generated:
```
DWA compression Size (bytes)
Before the change 750 175,208,243
After the change 225 77,838,827
```
It is worth noting that the DWA compression seemed to be ignored in
the 4.4 branch before this change (this is what the original report is
about, a bit indirectly).
This is measured on the Fabrik Eingang footage converted to EXR. The
absolute value is ptobably not that important, it just shows the
reduction in size. This also leads to a lower quality of the proxy
image, but it is not worse than an actual JPEG proxy: the quality is
set to rather low 50 for the strip proxies.
Ref #134802
Pull Request: https://projects.blender.org/blender/blender/pulls/135103
The `with_smoke` case is handled correctly and checks for reallocation,
but the liquid case was ignored for unknown reasons.
The `with_smoke` distinction was added years ago (c7596cd820)
but for some reason the `with_liquid` case was ignored for reallocation.
Pull Request: https://projects.blender.org/blender/blender/pulls/135247
The code-path for coercing a dictionary to operator/gizmo properties
was being used RNA functions where it's not supported.
Raise a type exception instead of crashing.
Suppress exporting this attribute as there's no conversion to USD that
supports its data type (2d, 16-bit int) and because mesh normals (from
the `corner_normals` API) are already exported. This causes a rather
annoying UI Warning notification that the attribute isn't convertible
during export.
Pull Request: https://projects.blender.org/blender/blender/pulls/135271
With 4c67c78452 we changed the default theme color for front faces,
used by the Face Orientation overlay, to have zero alpha so that it
could be used in more cases. But versioning updated this for all old
files, which can overwrite users who made deliberate changes to it.
This PR alters the versioning code to only change the color if it
currently exactly matches the old default.
Pull Request: https://projects.blender.org/blender/blender/pulls/135262
The visibility of Geometry Nodes gizmos sometimes depends on the
selected nodes in a node editor. Therefore, when the editor is closed,
the set of available gizmos has to be refreshed.
The enum items propagation mechanism for Menu sockets makes a local copy of item
pointers to propagate between node group inputs and interface definitions.
In case these items are not used (e.g. because they are already shared with the
socket) the local copy must still be released to avoid leaking the memory.
This only happens with more than 4 enum items, because of the internal default
buffer for `Vector`.
Pull Request: https://projects.blender.org/blender/blender/pulls/135226
Multiple panels of material in properties tab were not
collapsed/expanded when click-dragged over them. This is because wrong
button type for interface-panel. To support multi-drag, button has to be
of type toggle, see: `ui_do_but_ANY_drag_toggle()->
ui_drag_toggle_but_is_supported`
Pull Request: https://projects.blender.org/blender/blender/pulls/135154
- Refactor tagging logic into a function to remove duplicate code
The two phases of tagging were identical logic just with the variables
and tag values swapped. This change ensures the two loops use matching
behavior.
- Adjust iteration to prevent restarting from the beginning of the mesh
after each island.
- Simplify and speed iteration tests.
testing to ensure v->e is non-null is redundant - verts with no edges
would never have passed `bm_vert_dissolve_fan_test` in the first
place, so can't be tagged as `VERT_INDEX_INIT`.
Re-testing `bm_vert_dissolve_fan_test(v)` is redundant - it was
checked above, and during tagging, the topology does not change.
Topology only changes later, after tagging is complete.
Therefore it's guaranteed to return the same result as the first time.
- Simplify loop logic, rename vars for clarity
offset and nth were constants, and depth was what causes alternation.
However none of that math is necessary - it can simply be done with
call order.
'seek_a' and 'seek_b' were renamed to what they actually are - lists
of verts that are tagged for collapse and ignore, respectively.
Further, by checking if any verts were tagged during the first
iteration pass, the second iteration pass can be avoided entirely if
it will perform no work.
Ref: !135212
For MacOS, when hovering your mouse over the area corner "action zones"
the Status Bar shows a "Swap Areas" item that has unnecessary spacing
between the Control modifier key icon and left mouse button icon. This
is because I forget different icons were shown for Mac. This PR just
uses the proper calculated spacing that knows better.
Pull Request: https://projects.blender.org/blender/blender/pulls/135208
Our text wrapping code is written in a way that requires the Line Feed
character to be in our glyph cache. This is problematic as none of the
control characters will ever be there if not using fallback. With
fallback these glyphs could be a zero-width character from a symbol
font, or something with width if using a last resort font. So we'd have
to ignore the advance in the latter case. This came to a head recently
because we are turning off fallback in some circumstances. 12b1f8bd7a
removed the rendering of control characters so they are never in the
cache. That change requires this one, which does wrapping based on the
string's codepoint, not that of its glyph.
Pull Request: https://projects.blender.org/blender/blender/pulls/135196
Same was true for SimpleDeform.
Invert vertex group influence should only have an effect if there is a
group specified.
Shrinkwrap always uses a weight (gets weights via
`BKE_defvert_array_find_weight_safe` -- which gets full weight for no
group specified, rightfully so), if this gets inverted, we get no
influence at all.
Now move the inverting of the weights to `BKE_defvert_array_find_weight_safe`,
adjust the other callers accordingly (Bevel also does not need to check for a valid
vertexgroup beforehand).
Pull Request: https://projects.blender.org/blender/blender/pulls/121625
Since the transform system uses previous positions to update to
"original" positions upon cancel, the elastic transforms are not working
well with this (due to their `TransformDisplacementMode::Incremental`
nature).
To resolve, rely on restoring positions from undo (as done elsewhere in
sculpt).
Pull Request: https://projects.blender.org/blender/blender/pulls/134919
`BKE_modifier_copy_ex` did it (which is called e.g. when copying the
whole stack from one object to another), but when simply duplicating a
modifier (`modifier_copy`), it was just ensuring a unique name (based on
the default name) without copyig the existing name prior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135172
When called on an object that you cannot get a mesh from (e.g. Empties),
you would run into an unhelpful "SystemError: <built-in method
FromObject of type object at ...> returned NULL without setting an
exception"
Now be more specific in the error message.
Pull Request: https://projects.blender.org/blender/blender/pulls/135162
Only a single `select` prop was exposed, and this was set to "bezt.f1"
(so it affected the left handle only).
Now we add properties for `left`, `right` and the `single` handle, the
selection prop for the control point is renamed to
`select_control_point` [which is now in line with the API for a bezier
curve].
NOTE: setting/getting a `single` handle uses the existing functions for
this -- handle is selected if any of the right/left handle is selected,
setting the handle results in both handles getting selected.
Pull Request: https://projects.blender.org/blender/blender/pulls/135114
Previously Grease Pencil simplify operator didn't take stroke selection
into account when it's running in Adaptive or Merge modes. Now filters
points with selected stroke to make all modes have consistent behaviour.
Note that the behaviour of simplify is to operate on the entire
stroke if there's anything selected on the stroke. This is consistent
with what we have prior to switching to Grease Pencil v3 (4.2 and prior)
Arguably some modes can be further improved by only work on selected
segments, but it's beyond the scope of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/134497
With recent changes to the matching of OS title bar to Blender colors
on MacOS and Windows, it looks far nicer to not show the editor border
for windows that only have a single area and also do not have any
global areas. This PR removes them in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/134961
This was happening because in `apply_eval_grease_pencil_data`
we gather all the potential original layers to clear. This was done
by taking the set of all original layers and then removing layers
from the set that map to an evaluated layer.
The remaining layers are unmapped and should be cleared.
The problem is that invisible layers are no longer part of evaluated
data so there wouldn't be a mapping that could be found.
To fix this, we don't initialize the set of `orig_layers_to_clear` to
all the layers, but instead to only the layers that are visible.
This will ensure that we don't clear keyframes of hidden layers.
Pull Request: https://projects.blender.org/blender/blender/pulls/135121
The emissions strength was only set when using an emissive texture.
Additionally, for colors brighter than 1.0, normalize the color
into 0..1 range and set the strength accordingly.
Pull-Request: https://projects.blender.org/blender/blender/pulls/135094
