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
Currently the remove material slot button still appears to be
active while in edit mode. Attempting to use the button will
result in an error "Unable to remove material slot in edit mode."
Solution is to edit poll function to disable/gray out the remove
material slot button while in edit mode similar to other buttons
In the code a check was added for edit mode for the operator
execution as a fix for bug #21822. However this check was never added
to the polling function. This commit adds that check.
Pull Request: https://projects.blender.org/blender/blender/pulls/139660
Some functions used at least once per object/instance
when drawing are so trivial that function call overhead
becomes significant. Allowing these functions to be
inlined can remove that overhead and also give the
compiler more information it can use for optimization.
In the Erindale Flower Shop file, this change gives me
a 10% improvement in playback FPS, from 8.77 to 9.65.
Pull Request: https://projects.blender.org/blender/blender/pulls/140402
In Blender 3.3 (1) the individual combine and separate color nodes were
combined together into a single combine/separate color node.
To ensure legacy addons still worked, the old nodes were left in
Blender, but hidden from the Add menus.
It has been nearly 3 years since that change was made, most if not all
addons should have been updated by now. So this commit removes these
hidden legacy nodes.
(1) blender/blender@82df48227b
Pull Request: https://projects.blender.org/blender/blender/pulls/135376
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
Extracted from PR !115967. Committed separately because otherwise, the
change in logic in that PR is lost in the renaming noise.
This commit is purely non-functional change.
Currently we have two entries in the Select menu:
- Box Select
- Box Select (Include Handles)
But since b037ba2665, Include Handles is the default, so both entries
behave exactly the same.
To resolve, make it:
- Box Select (Include Handles)
- Box Select
with the second one setting the "include_handles" option to False.
NOTE: behavior of "include_handles" option False might be a bit flaky in
certain situations as well (can be checked later), better to actually
have two entries that represent what the code does.
Noticed while checking on #139314
Pull Request: https://projects.blender.org/blender/blender/pulls/139347
This patch removes the Map Value node that was deprecated in 4.5 and was
planned for removal in 5.0. The common Shading Map Range node should be
used instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/140533
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.
This patch removes the Vector Curves node that was deprecated in 4.5 and
was planned for removal in 5.0. The common Shading Vector Curves node
should be used instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/140529
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
This was making the tests fail.
`gtao_distance` still needs correct versionning
even if deprecated. Also `fast_gi_distance` does
not correspond to `gtao_distance`.
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
