Caused by 6b0869039a
Above commit introduced selection after renaming. This includes calling
`file_select_deselect_all` [which resorts and refilters].
So now, to have the correct file for scrolling, get it again after
sorting by calling `file_params_find_renamed` again.
Differential Revision: https://developer.blender.org/D13368
A minor cosmetic fix. When the view was scrolled all the way to the
bottom, the lowest panel would end right on the view edge. The
scrollable view should get the same margin at the bottom as used at the
top.
This corrects some alignments issues through new margins introduced in
93544b641b. Basic idea of this fix is to only add the new margins when
drawing a panel with background. These margins were added specifically
for the background boxes, so that makes sense.
Alternative fix to D13199.
This also fixes some margings added unintentionally in mentioned commit.
There is a little jump of the toolbar and the tabs in the Properties
when comparing the UI without this fix to 2.93:
{F12158085} {F12158039}
The jump is gone with this fix applied (compare to the 2.93 screenshot):
{F12158064}
While not a serious issue, this confirms that this fix actually tackles
the root of the issue.
Don't use the side padding for menu item contents when displaying
previews or icons in a row or grid layout. This can cause problems for
the preview drawing and doesn't make sense to draw there anyway.
This not only fixes the mentioned issue, but also too small heighlight
for the collection color tag in the Outliner context menu.
Alternative to and similar to D13125.
Assigning a catalog to an asset via drag-and-drop in the asset browser
now creates an undo step. Not only does this allow undoing the action,
it also tags the blend file as modified.
Reviewed by: Severin
Differential Revision: https://developer.blender.org/D13370
This fixes a crash when muting the "Group Output" node.
It should not be possible to mute it so this patch
sets the `no_muting`-variable on it.
Differential Revision: https://developer.blender.org/D13364
Liboverride properties and operations list need to be fully up-to-date
before libraries are reloaded, otherwise re-applying those liboverrides
after linked data is reloaded may miss some changes.
This reverts the changes to fix T87448, where entering the same value in number
buttons causes an unnecessary update. This is not stable enough for 3.0 and so
is being reverted, better to have an unnecessary update than no update in other
cases.
This effectively reverts the changes from rBeb06ccc32462 and follow up fixes
rBe1a9ba94c599, rBbbb52a462ef9, rBec30cf0b742f, and rB071799d4fc44. The code is
disabled with a comment on how it could be implemented better.
Bug introduced in {rBaa0ac0035a0d}.
The invalid depth fallback was changed to `FLT_MAX` in order to match the
annotation and gpencil operations.
This broke the `Interactive Light Track` operator which invalidates the
operation if the depth value is `1.0f`.
The chosen solution was to change the value tested in the annotation and
gpencil operations.
Caused by {rBcf2baa585cc8}.
For Curve Guide force fields to work, the `Path Animation` option has to
be enabled. With it disabled, we are lacking the necessary
`anim_path_accum_length` data initialized [done by
`BKE_anim_path_calc_data`] which `BKE_where_on_path` relies on since
above commit.
Now just check for this before using it - and return early otherwise.
Prior to said commit, `BKE_where_on_path` would equally return early
with a similar message, so that is expected behavior here.
Maniphest Tasks: T93338
Differential Revision: https://developer.blender.org/D13371
The issue was that the attribute propagation in the Fillet Curve node seems
pretty broken. I couldn't really make sense of the old code. It changed the
size of the point attribute domains on splines to 1 for some reason which
led to a crash in the next node.
Differential Revision: https://developer.blender.org/D13362
The mirror modifiers merge option caused unnecessary re-ordering
to the vertex array with original vertices merging into their copies.
While this wasn't an error, it meant creating a 1:1 mapping from input
vertices to their final output wasn't reliable (when looping over
vertices first to last) as is done in
BKE_editmesh_vert_coords_when_deformed.
As merging in either direction is supported, keep the source meshes
vertices in-order since it allows the vertex coordinates to be extracted.
NOTE: Since this change introduce issues for some cases (e.g. bound
modifiers like SurfaceDeform), this change is only applied to newly
created modifiers, existing ones will still use the old incorrect merge
behavior.
Reviewed By: @brecht
Maniphest Tasks: T93321, T91444
Differential Revision: https://developer.blender.org/D13355
Revert "Fix T91444: Edge Loop Preview fails with two Mirror Modifiers"
This reverts commit 1a7757b0bc.
Caused issue reported in T93321, boiling down to the fact that other
operations or modifiers (like the SurfaceDeform one) rely on the order
of the vertices in the mesh to remain consistent.
Changing this in a modifier would mean those operations need to be
reset/re-created (e.g. rebound for the SurfaceDeform case), which is not
doable in `do_version` code.
A parallel loop to create the interesection meshes for each triangle
meant that with parallelism, the output order of the created meshes
could vary with each execution. Keep the parallelism for doing the CDTs
for interesection, but move the extraction of the new faces into a
serial loop afterwards, for repeatability.
This commit improves the scaling of some ui widgets when
zooming by making the radius of the rounded corners
dependent on the element's zoom level.
Needed to fix T92278 without padding issues, see D13125.
Reviewed By: Hans Goudey, Julian Eisel
Differential Revision: https://developer.blender.org/D12842
There are two functions that recalculate the boundbox of an object:
- One that considers the evaluated geometry
- Another that only considers the object's `data`.
Most of the time, the bound box is calculated on the final object
(with modifiers), so it doesn't seem right to just rely on `ob->data`
to recalculate the `ob->runtime.bb`.
Be sure to calculate the BoundBox based on the final geometry and
only use `ob->data` as a fallback
Differential Revision: https://developer.blender.org/D12282
Changes icon used to indicate blend file when overlaid over larger
document icon when in thumbnail view. Only seen when file does not
have a preview.
Followup to {rB611e4ffaab43}
For more details and examples see D13342
Differential Revision: https://developer.blender.org/D13342
Reviewed by Julian Eisel
Changes icon used to indicate blend file when overlaid over larger
document icon when in thumbnail view. Only seen when file does not
have a preview.
Followup to {rB611e4ffaab43}
For more details and examples see D13342
Differential Revision: https://developer.blender.org/D13342
Reviewed by Julian Eisel
Without this it's easy to loose track of which catalog you are dragging.
Things feel generally quite jumpy/disconnected, activating the catalog
makes things feel far less like that.
I consider this an important usability fix, therefore I'm adding it to
the release branch.
When dropping catalogs it is ensured that the name of the moved catalog
is unique within the new parent catalog. When dropping a catalog into
the parent, the catalog would not actually move to a different location,
but it would still be renamed. The unique name logic simply isn't smart
enough to ignore the catalog that is about to be moved.
Address this by disallowing dragging a catalog into its own parent. It's
already there.
This was an oversight when I added catalog drag & drop support. I forgot
to add this for dragging catalogs into the top level by dragging into to
the "All" item as well. This made the drag & drop support rather broken
because it wouldn't work for a basic case.
When a node is executed, it usually schedules other nodes.
Right now, those newly scheduled nodes are added to a
task pool so that another thread can start working on them
immediatly.
However, that leads to the situation where sometimes each
node in a simple chain is executed by another thread. That
leads to additional threading overhead and reduced cache
efficiency (for caches that are not shared between cores).
Now, when a node is executed and schedules other nodes,
the first of those newly scheduled nodes will always be
executed on the same thread once the current node is done.
If it schedules more than one other node, those will be
added to the task pool as before.
The speedup achieved by this is hard to measure. I found it
to be a couple percent faster in some extreme cases, not
much to get excited about. It's nice though that the number
of tasks added to the task pool is commonly reduced by a
factor of 4 or 5.
This part of the drawing code assumes that the bone custom object
has only one evaluated geometry component, and it also uses the
object type to check which data to draw, with the functions like
`DRW_cache_object_surface_get` that just take an object input.
Those functions usually work on evaluated objects, which use the
instancing system to access a temporary object with `object.data`
replaced for data types that don't match the original object.
That assumption used to work, but now curve, point cloud, or volume
objects can have an evaluated mesh which is not accessed with the
same object for render engine drawing.
The "correct" solution for the way this code is structured would be to
loop through all of the geometry components and try to get GPU batches
from every one of them. However, that significantly increases complexity
in an area that should probably be refactored anyway. This patch treats
the mesh as a special case, and only draws the evaluated mesh.
The **best** solution in my opinion might be refactoring this area to
use the instancing system with some sort of viewport-only flag so
the custom shape instances aren't added in the render.
The solution is "partial" because the "Wireframe" option only works
for meshes from mesh objects, even after this fix, and because other
data besides meshes is not displayed at all.
Differential Revision: https://developer.blender.org/D13038
When a manual frame range is set, allow marking an action as having
Cyclic Animation. This does not affect how the action is evaluated,
but the Cycle-Aware Keying option will automatically make any newly
added F-Curves cyclic. This allows using the option from the start
to build the cycle, rather than only for tweaking an existing loop.
The curves are made cyclic when they have only one key, either
after inserting the first key, or before adding the second one.
The latter case avoids the need to manually make the first added
curve cyclic after marking a newly added action cyclic.
Differential Revision: https://developer.blender.org/D11803
Some operations, e.g. adding a new action strip to NLA, require
knowing the active frame range of an action. However, currently it
can only be deduced by scanning the keyframes of the curves within
it. This is not ideal if e.g. curves are staggered for overlap.
As suggested by Nathan Vegdahl in comments to T54724, this patch adds
Action properties that allow manually specifying its active frame range.
The settings are exposed via a panel in the Dopesheet and Action Editor.
When enabled, the range is highlighted in the background using a striped
fill to distinguish it from the solid filled regular playback range.
When set, the frame range is used when adding or updating NLA tracks,
and by add-ons using `Action.frame_range`, e.g. FBX exporter.
Differential Revision: https://developer.blender.org/D11803
Add a new 'selected_visible_actions' property to allow querying
actions that are selected in animation related editors for use in
UI and operators. The 'selected_editable_actions' variant excludes
linked actions (the only reason an action can be read-only).
In the Action and Shape Key editors there is only one action
that is specified by the field at the top of the editor.
In Dope Sheet it scans the channel rows and returns all actions
related to the selected items. This includes summary items for
actions and groups.
In Graph Editor, it lists actions associated with selected curves.
The new property is also used for Copy To Selected and Alt-Click.
Ref D11803
This is only meant to be used for development purposes for now,
not to show warnings to the user.
Differential Revision: https://developer.blender.org/D13348
Previously, there were a couple of cases where nodes were scheduled when
that was not really necessary. This change doesn't seem to have a big impact
on performance, but simplifies the code a bit.
