The code around view transform selection accidentally got too coupled
to the scene. However, the file output settings do not have scene, so
the enumerator getter was crashing.
Caused by 7ceb4495c5.
This patch brings the code closer to the Blender 4.4 behavior by
maintaining a global from view name to an ID.
There is still a bug in the code which displays views from the active
scene's display settings in the override panel. This is because the
itemf() callback is hardcoded to use the display settings from the
active scene (via bContext). However, this issue exists since the
initial commit of the color management override option.
Pull Request: https://projects.blender.org/blender/blender/pulls/140729
When movie strip is added and redo panel is tweaked, operator failed to
re-execute.
Caused by c4eab49b9. This added `sequencer_generic_invoke_xy__internal`
call in operator exec function, but did not specify `SEQPROP_NOPATHS`
argument, which caused `directory` and `filepath` properties to be
overwritten.
This PR adds clarification for `SEQPROP_NOPATHS` use case, because it
isn't immediately obvious what this is doing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140736
Correct an oversight in df6d345bb4: without proportional editing, all
the transform data is "selected" by definition. This means that the
assumption "the selected data is sorted first in the array" is
trivially true, without calling any sorting function. So instead of
using the sorted index map in these cases, just fall back to regular
iteration.
To make the code handle this nicely, I made two "foreach" functions.
The first one transparently uses the sorted index map when available,
and performs regular iteration otherwise. The second function only
visits the selected items.
This makes the usage of these functions clearer, and the fact that
selected items are expected to be sorted first (either trivially or
explicitly) can be documented in a central place.
Pull Request: https://projects.blender.org/blender/blender/pulls/140720
Restore expected behavior of the NDOF, especially in the context of
non-3D editors. It addresses the following issues:
- Object mode, 3D viewport:
With "Lock Horizon" off, the rotation axes will invert unexpectedly,
making the camera behave similar to a "Fly mode".
- Fly mode, 2D editors:
Changing a navigation mode to "Fly" makes no effect.
Applies to UV and Nodes editors, Camera Preview etc.
Related to #140165
This includes some minor API changes back-ported from `main`
since the PR was created for `main`.
Co-authored-by: Patryk-Skowronski <patryk_skowronski@3dconnexion.com>
Ref !140537
Incoming string attributes from USD have never been fully processed yet
they were added to our list of convertible types. This list originally
came from the Mesh reader before it was made common, but for Meshes the
string type was being skipped elsewhere so there was no harm. Now that
Point Clouds and Curves use this common code, it does matter.
Files containing string attributes for these object types will hit the
`BLI_assert_unreachable` call inside `copy_primvar_to_blender_attribute`
and trace an error to the console requesting the user to file bugs. This
was discovered while looking into the old Moana scene.
Remove the string entry for now as there's no regression in behavior and
it prevents the assert from firing (functionally harmless in Release
builds but the output to the terminal is unnecessary).
Pull Request: https://projects.blender.org/blender/blender/pulls/140681
When creating depsgraph relationships for drivers, avoid creating the
'unshare' depsgraph node for drivers on custom properties and on
shapekey `value` properties.
This should fix a significant part of the performance regression
mentioned in #140706.
Pull Request: https://projects.blender.org/blender/blender/pulls/140724
Resolve reference counting error in the RNA API which mixed up ownership
between ExtensionRNA::data & StructRNA::py_data.
In practice this generally worked as RNA_struct_free_extension behaved
as if ExtensionRNA owned the reference instead of StructRNA, so as long
as only one reference was removed, there wasn't any difference.
When re-registering Python classes with RNA, ownership wasn't handled
properly which could result in negative reference counts,
crashing in some cases.
After using the Purge Unused Data operator, hovering mouse over outliner
makes outliner tree dirty as the tree is not being rebuilt. The operator is
defined in python which calls `ANIM_armature_bonecoll_remove`. Add
notifier in that function code so that `outliner_main_region_listener`will tag
the outliner region for full redraw.
Pull Request: https://projects.blender.org/blender/blender/pulls/140256
Python 3.14 has moved some functionality into the public API,
use the updated names even with older Python versions.
Also resolve an error caused by variable reuse with delayed annotation
evaluation for TextureProperties_MixIn on startup.
Resolve#140695.
When dragging an area from one window to another it is possible for the
bScreen->active_area to be be invalid for a short period of time. This
is constantly updated so normally not noticeable but will cause ASAN
errors when trying to show keymaps in the status bar as this is use
after free. This PR just sets these to nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/140683
`UI_icon_from_idcode` is used e.g. from the Action Editor to indicate an
Action's Slot Type (and without the icon it is kinda hard to tell what
the slot is suited for...)
Before
After
Discovered while investigating #140618
Pull Request: https://projects.blender.org/blender/blender/pulls/140658
After a recent commit, multiple drawings were always written using the
same address because we used the same stack memory in a loop. This
causes the blend file reading to not be able to distinguish between the
structs, meaning the file is corrupt. However, we already had the same
problem in some cases because of the inline buffer in `BlendWriteData`.
To resolve this, make all "temporary" data for writing live as long as
the writing is going on for the ID. This is somewhat inefficient since
it makes memory reuse impossible for this temporary data. In the future
we should use a technique like #127706 to address this.
For testing, I saved and loaded multiple production files with Grease
Pencil objects, with and without the "write with attribute storage"
option enabled. The fix still goes to 4.5 though, because the first
mentioned issue is present there, and the `CustomDataLayer` vector
address reuse is potentially a problem too.
Pull Request: https://projects.blender.org/blender/blender/pulls/140667
Fix#79163 bug related to the bevel operation producing disconnected UVs for
new bevel faces. This change replaces previous approach using scattered and
selective usage of functions: bev_merge_uvs, bev_merge_edge_uvs and
bev_merge_end_uvs with one coherent technique for all stages of the bevel operation.
It is utilizing a concept of loop (BMLoop) buckets to keep track of UV vertices
that should be merged at the end of bevel operation by a single call to
bevel_merge_uvs function. This approach doesn't touch initial UV position
calculation done by interpolation algorithm in bev_create_ngon function and
keeps the concept of representative faces (called frep, facerep or rep_face in
code) to help decide to which bucket specific loops should be assigned.
This is from PR https://projects.blender.org/blender/blender/pulls/139595,
which has more explanation and discussion.
GreasePencil ID type did not list `ID_OB` as its potential ID dependency
type, leading to lack of remapping of its layers' parents objects
pointers (e.g. on Object deletion), leading to crash from accessing
freed data.
We detected that the gpu/draw tests could lead to
crashes after the tests where finished. It was
identified that the crash happened as the submission
runner wasn't exited, uses a mutex, that is being
destroyed by the main thread.
Solution is to wait until the submission runner has
finished, before destroying resources.
Pull Request: https://projects.blender.org/blender/blender/pulls/140650
Avoid modifying the order of transform system data. Instead, create an
index map and use that to traverse the data arrays in sorted order.
The issue observed in #139042 stems from the assumption, in _some_ of
the code, that `tc->data[i]`, `tc->data_ext[i]`, and `tc->data_2d[i]`
all contain information about the same "transformable thing". Since
`tc->data` was sorted (by selection state and, optionally for
proportional editing, by distance) but the other arrays were not, this
caused issues.
The most obvious solution, sorting all arrays the same way, turned out
to be hard to do, as some elements in one array have pointers to
elements in another array. Reordering those arrays would therefore
also make it necessary to find and update those pointers.
Instead, I decided to implement a sorted index map. The arrays can
then be kept in their original order, and the index map can be used to
visit them in sorted order.
Pull Request: https://projects.blender.org/blender/blender/pulls/140132
The issue was that the wrong flag was passed to
`ANIM_nla_mapping_apply_if_needed_fcurve` resulting
in the handles not moved back in this method.
This issue was only visible when pasting on top of a single keyframe,
or when the key had free handles. That is because the handles would
be recalculated otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/140542
MESH_GGT_spin_redo (for the operator) depended on MESH_GGT_spin
(for the tool) having already been initialized however the order
gizmos are initialized currently isn't guaranteed.
Workaround the problem by adding a null check.
See the report for details.
Co-authored-by: Philipp Oeser <philipp@blender.org>
The logic to access the edit-mesh for the selection engine didn't match
the logic used for drawing.
Resolve using the edit-mesh from: BKE_object_get_pre_modified_mesh
Ref !140525
Some USD files have the displacement input specified in the shader but
do not have it marked as an output in either the shader or the material.
Skip processing if we do not have a valid displacement source.
Pull Request: https://projects.blender.org/blender/blender/pulls/140619
`blend_write_prepare` expects to work on a shallow copy of the
`CurvesGeometry` struct. This is necessary because it changes
the struct to contain only the layers being written. This is
particularly important with writing with the new format enabled,
where attributes are written as part of `AttributeStorage`.
Writing with a shallow copy of the struct also gives us the
flexibility to zero the runtime pointer in the written file which
is generally a good practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/140560
For UILists that doesn't use `filter_items()`, search filter doesn't work
along with invert button. For filter_items, invert case is already
handled in filter_items_by_name. In absense of that function,
handle the invert case inside `UI_list_filter_and_sort_items`. Existing logic
is a bit wrong. Now flags are adjusted, i.e. when search string matches, check
for invert status to decide whether items should be in the list or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/139523
This was caused by a hash colision caused by an incorrect
auto conversion from `Object*` to `ObjectRef`. The `ObjectRef`
would then not contain any instancing data and would create
the same hash for the same particle system on each instance
(since only `foreach_hair_particle_handle` was constructing
`ObjectKey` from an `Object*` it did not affect the instance
itself).
Marking the incriminating constructor `explicit` to avoid
more issues. Changing the `ObjectKey` creation for psys to use
`ObjectRef` fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/140544
We should never select something that is hidden in the viewport.
Generally, there can be multiple reasons why keyframe handles are not
shown in the Graph Editor:
- the `View` > `Show Handles` option is disabled
- the `Only Show Selected Keyframes Handles` is enabled
- a keyframe `Interpolation` method is anything but `Bezier`
This PR corrects the first.
Details:
- In `box_select_graphkeys()`, the `incl_handles` parameter is only
be passed to `initialize_box_select_key_editing_data()`
- add a separate `KEYFRAME_ITER_HANDLES_INVISIBLE` flag (representing
SIPO_NOHANDLES)
- "include_handles" purely represents operator setting / user intend now
- "final" decision about handles/their visibility is done in
`keyframe_ok_checks()` etc
For consistency, add "include_handles" option to Lasso/Circle as well
Part of #139314
Pull Request: https://projects.blender.org/blender/blender/pulls/139349
Add an optional init function which operators
An alternative to [0] which missed Python API support (causing #140451).
While that could be resolved, tracking which "slots" have been set
would have to be flagged on every map/hash insertion which seems
excessive and is prone to bmesh operators failing if the flag is ever
missed. Prefer a simpler init function so dissolve edges doesn't have
a zero threshold.
Also support multi-line comment blocks in the generated API docs.
[0]: bd3a66a416
The "delete this F-Curve" function assumes that the F-Curve is either a
driver or contained in `adt->action`. This does not have to be true, as
the Action editor can also show F-Curves from other uses (for example an
NLA strip). The channel delete operator (`ANIM_OT_channels_delete`) now
takes this into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/140291
LoongArch is a new RISC ISA developed by Loongson, this adds the missing
entry to BLI_build_config.h. It has been verified to work on Arch Linux's
loong64 port.
Pull Request: https://projects.blender.org/blender/blender/pulls/130916
Also true (and reported) for the general File Browser.
In the implementation from 5a67407d5a it was noted that including the
active file was desirable(next to `FileSelection` `first` and `last` of
course).
`FileSelection` indices get correctly updated after search is altered/
cleared (by `file_current_selection_range_get`), the `FileSelectParams`
`active_file` however isnt.
This makes the framing go wrong when search is altered or cleared (it
uses an index from the previous/outdated filter result).
I case of the Asset Browser (in main) this was also obvious when you
looked at an active asset in the sidebar -> clearing a search (after
having selected something while searching) for example would make a
"completely different" asset active.
Since keeping track of a "previous" `active_file` (and trying to update
to an updated/correct index) turned out to be quite hairy, this PR goes
the route of actually clearing the `active_file` on search updates. Like
mentioned, this is still not ideal (at least for the Asset Browser, it
looses the "active" of something selected), but at least now you can
easily frame it again -- and is is better than in main (where "active"
would point to something completely unrelated and you could not even
frame it to click-activate it again).
Pull Request: https://projects.blender.org/blender/blender/pulls/140365
Create a good default name for saving individual frames of a movie file loaded
as an image datablock, instead of the movie file name.
Changes ImBuf to store the frame separate from the filepath, to implement this.
Seems more clear for ImBuf.filepath to be an actual filepath anyway.
Thanks to Jesse and Aras for investigating this bug.
Pull Request: https://projects.blender.org/blender/blender/pulls/140471
The previous logic was not triggering parallel compilation
for DoF and Fast GI shaders. This led to slower initialization
time for the default shader preview or render.
If block added in 52b8eba9eb actually
seems reduandant (invert still shows all elements for empty string).
Due to the `filter_byname` condition, custom property used for search
filtering was useless as UI_list_item_index_is_filtered_visible returned
true for all elements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139518
Unlike object or posemode (where items not only need to be active but
also selected to be treated as a starting point for cycling through to
the next item behind it on the next click), armature editmode would
treat active (but unselected) bones as a starting point as well. Leading
to confusion if you just clear your selection prior.
For reference to the expected behavior, look at these comments in
`mouse_select_eval_buffer`
>/* Only exclude active object when it is selected. */
>/* When the active object is unselected or not in `buffer`, use the
nearest. */
Now for editbones, the way `get_nearest_editbonepoint` works, there were
actually two things preventing stuff from happening as expected:
- [1] we would still get "use_cycle" behavior if we have an unselected
(active) bone -> this is now checked for by looking at active bone
selection flags (NOTE: tip/root needs to be looked at as well). These
checks were once there, bd59781c66 removed them though.
- [2] without "use_cycle" behavior, we are still looping all hit bones
and there could be the situation where we could accept a first bone (in
the `bias > bias_max` condition -- that one could be the closest already
but does not set the `min_depth`), but continue to loop (now entering
the "bias == bias_max && do_nearest" condition and `min_depth` could
still be at INT_MAX) and accept a bone that is actually further away...
That logic is from 328ec2b172
Both points have now been addressed.
Pull Request: https://projects.blender.org/blender/blender/pulls/140348
Depth navigation sends many small render graphs to the device. It can be
that a subsequent render graph uses the same shader as the previous one
with the same descriptor set tracker. The descriptor set tracker didn't
cleared its full state and a subsequent render graph was generating
commands assuming that the device was in a certain state.
However it wasn't and a command to bind a descriptor set was skipped
resulting in a device out of bound write. Depending on the platform this
could overwrite any data on the GPU, including shader programs as the
select shader writes to a storage buffer. This clarifies why the issue
resulted in very odd and none consistent behavior.
This PR fixes this by clearing the VKPipelineData and
VKDescriptorTracker.
Pull Request: https://projects.blender.org/blender/blender/pulls/140526
Two issues here:
- if only one bone is selected blender would create an **Empty** as
target (does not make sense as a target for an armature constraint
though)
- if other bones are also selected, none would be set up as a real
target for the Armature Constraint
So to resolve, change behavior in the following way:
- if only one bone is selected -> dont create a "dummy" target at all
(just like for `Clamp To` or `Spline IK`, does not really make sense to
create a default Curve / Armature in this case since the user would
always use something else)
- if you have another bone selected -> set it up as bone target in the
armature constraint for the user
For the second to work properly, we have to add a target to the armature
constraint "manually" (since armature constraints dont have a target by
default)
Pull Request: https://projects.blender.org/blender/blender/pulls/140200
