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
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
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
Device::const_copy_to is sometimes called when the Embree BVH has been freed
and not replaced yet. Previously this was a simpler pointer copy, now there is
a function call. Make sure it's just a function copy.
Thanks to Nikita Sirgienko for figuring this out.
Pull Request: https://projects.blender.org/blender/blender/pulls/140457
Previously there was no way to select/manage the action and slot
assigned to most kinds of node trees. This addresses that oversight.
This applies to all node trees that are not embedded IDs.
Pull Request: https://projects.blender.org/blender/blender/pulls/140347
Previously `blend_name` was using the same path to get its file name
as `//` used. However, the choice of path for `//` seems to be
bespokely chosen at each call site. There may be a logic to it, but
if so it's not immediately clear what it is.
This PR changes `blend_name` to instead always use the currently open
("global") file path, making it well-defined and predictable for
users.
This also prepares better for PR #139438 for 5.0, which adds
`blend_name_lib`, which always uses the blend file that the ID owning
the path is linked from. Over-all this should be much more predictable
and controllable for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/140474
The BMesh python API was fully broken by this commit.
While the fix seems to be reasonably simple, it is safer for now to revert
the faulty commit, as the breakage is fairly impactful for people using 4.5
and/or 5.0 daily builds.
This reverts commit bd3a66a416.
- Removes asserts where polygon shaders are used to draw lines and
points. This is incorrect and leads to asserts in Vulkan.
- Kept as close to the existing control flow. Didn't want to introduce
regressions as this PR lands in 4.5
Pull Request: https://projects.blender.org/blender/blender/pulls/140337
Nodes code uses direct access to enum property values definition
(outside of the RNA API) to generate UI (translated) messages, this is
risky/messy since the i18n context potentailly defined for the actual
RNA property is not available in these cases.
A few reports used string formatting in a way which made translation
awkward, by splitting the message into several individually translated
submessages, instead of just one message with formatting markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/139895
Fix a crash in the inbetweener (and other similar tools) when bones have
custom properties, but no system properties. It just needed another
`nullptr` check.
Pull Request: https://projects.blender.org/blender/blender/pulls/140455
When initially saving a file, we would now always create a catalog
definition file that would be writted to disk on file save. This
shouldn't be done if there are no new catalogs to write.
