This commit takes the 'Slotted Actions' out of the experimental phase.
As a result:
- All newly created Actions will be slotted Actions.
- Legacy Actions loaded from disk will be versioned to slotted Actions.
- The new Python API for slots, layers, strips, and channel bags is
available.
- The legacy Python API for accessing F-Curves and Action Groups is
still available, and will operate on the F-Curves/Groups for the first
slot only.
- Creating an Action by keying (via the UI, operators, or the
`rna_struct.keyframe_insert` function) will try and share Actions
between related data-blocks. See !126655 for more info about this.
- Assigning an Action to a data-block will auto-assign a suitable Action
Slot. The logic for this is described below. However, There are cases
where this does _not_ automatically assign a slot, and thus the Action
will effectively _not_ animate the data-block. Effort has been spent
to make Action selection work both reliably for Blender users as well
as keep the behaviour the same for Python scripts. Where these two
goals did not converge, reliability and understandability for users
was prioritised.
Auto-selection of the Action Slot upon assigning the Action works as
follows. The first rule to find a slot wins.
1. The data-block remembers the slot name that was last assigned. If the
newly assigned Action has a slot with that name, it is chosen.
2. If the Action has a slot with the same name as the data-block, it is
chosen.
3. If the Action has only one slot, and it has never been assigned to
anything, it is chosen.
4. If the Action is assigned to an NLA strip or an Action constraint,
and the Action has a single slot, and that slot has a suitable ID
type, it is chosen.
This last step is what I was referring to with "Where these two goals
did not converge, reliability and understandability for users was
prioritised." For regular Action assignments (like via the Action
selectors in the Properties editor) this rule doesn't apply, even though
with legacy Actions the final state ("it is animated by this Action")
differs from the final state with slotted Actions ("it has no slot so is
not animated"). This is done to support the following workflow:
- Create an Action by animating Cube.
- In order to animate Suzanne with that same Action, assign the Action
to Suzanne.
- Start keying Suzanne. This auto-creates and auto-assigns a new slot
for Suzanne.
If rule 4. above would apply in this case, the 2nd step would
automatically select the Cube slot for Suzanne as well, which would
immediately overwrite Suzanne's properties with the Cube animation.
Technically, this commit:
- removes the `WITH_ANIM_BAKLAVA` build flag,
- removes the `use_animation_baklava` experimental flag in preferences,
- updates the code to properly deal with the fact that empty Actions are
now always considered slotted/layered Actions (instead of that relying
on the user preference).
Note that 'slotted Actions' and 'layered Actions' are the exact same
thing, just focusing on different aspects (slot & layers) of the new
data model.
The "Baklava phase 1" assumptions are still asserted. This means that:
- an Action can have zero or one layer,
- that layer can have zero or one strip,
- that strip must be of type 'keyframe' and be infinite with zero
offset.
The code to handle legacy Actions is NOT removed in this commit. It will
be removed later. For now it's likely better to keep it around as
reference to the old behaviour in order to aid in some inevitable
bugfixing.
Ref: #120406
Part of the brush assets project followups, see #116337.
Based on feedback, it seems important to indicate to the user when a brush has
unsaved changes.
There's no reliable updating mechanism we can use or hook into here, except for
RNA "update" callbacks. Brush data gets changed in many places in code, the only
way to do this seems manual tagging every time a brush property gets changed.
This PR introduces `BKE_brush_tag_unsaved_changes()` for this. I spent some time
going through all brush properties to ensure changes call the tagging function.
A known limitation with this will be that changes to dependencies won't be
indicated in the brush. E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed.
The UI to indicate the changed brushes is being discussed still, see #128846.
Pull Request: https://projects.blender.org/blender/blender/pulls/128845
The main goal is to simplify adding support for nested node panels. The patch
makes use of the updated recursive node declarations introduced in
6ffc585fb8.
The main changes are:
* Rewritten node drawing in a way that makes ui design decisions like panel
visibility and margins more explicit. Especially the handling of margins is
much better now imo. Previously, it was very hard to change the margin for
specific cases without accidentally breaking other situations. Now each
possible case has an explicit margin. This needs a few more lines of code but
is much easier to work with.
* Rewritten node drawing in panel (sidebar + material properties) using the new
ways to iterate over the declaration.
* It's possible to add custom layouts at any point in the node declaration now.
This also replaces the need for having a `draw_buttons` callback for panels.
Pull Request: https://projects.blender.org/blender/blender/pulls/128822
Replace 'over-allocation' by a standard `blender::Vector` storage for
the `wmGizmoProperty` target properties of the gizmo. This simplifies code somewhat, and
makes the code ready to manage non-trivial types of data.
Explicit default values are also given to all data of `wmGizmoProperty`,
as it appears that the default constructor will not nullify values in
the (trivial) embedded `custom_func` struct.
NOTE: There is much more that could be done in the wmGizmo area to make
it use modern C++ features. The scope of this refactor is strictly
limited to allowing C++ construction/destruction of the wmGizmoProperty
data, as it embeds a PointerRNA pointer that will soon become
a non-trivial C++ struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/128763
This refactor contains the following changes:
* Each `PanelDeclaration` contains its direct children. Previously, it only knew
how many children it had. That added complexity to wherever we iterate over
the node declaration.
* Adds a new `DeclarationListBuilder` that is a base class of
`NodeDeclarationBuilder` and `PanelDeclarationBuilder`. It makes sure that the
same API for adding sockets, panels and separators exist for both.
* Modified declare functions for group, group input and group output nodes to
use the normal node builder api instead of doing something custom.
No functional changes are expected.
The main reason for this refactor is to simplify working with nested panels in
node declarations which is useful when we want to support nested panels in the
node editor. The node drawing code is not simplified in this patch, but that
should be easier afterwards.
Pull Request: https://projects.blender.org/blender/blender/pulls/128799
Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
When operator property is tweaked in preferences > keymap > "any operator",
preferences are not tagged dirty, which prevents writing the userpref
file at `WM_exit_ex` when auto-save is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/128516
This is due to wrong `is_pad` is passed as argument. It should be false
for gizmo tooltips. For menus when fields size is zero i.e. no
element is appended yet, the python message will be at the top of
tooltip region.
Pull Request: https://projects.blender.org/blender/blender/pulls/128243
This renames the mode identifiers to be consistent with e.g. the context mode identifiers and other names used for the new Grease Pencil.
For `object.mode`:
* `PAINT_GPENCIL` -> `PAINT_GREASE_PENCIL`
* `SCULPT_GPENCIL` -> `SCULPT_GREASE_PENCIL`
* `VERTEX_GPENCIL` -> `VERTEX_GREASE_PENCIL`
* `WEIGHT_GPENCIL` -> `WEIGHT_GREASE_PENCIL`
For the internal `ob->mode` flag:
* `OB_MODE_PAINT_GPENCIL_LEGACY` -> `OB_MODE_PAINT_GREASE_PENCIL`
* `OB_MODE_SCULPT_GPENCIL_LEGACY` -> `OB_MODE_SCULPT_GREASE_PENCIL`
* `OB_MODE_VERTEX_GPENCIL_LEGACY` -> `OB_MODE_VERTEX_GREASE_PENCIL`
* `OB_MODE_WEIGHT_GPENCIL_LEGACY` -> `OB_MODE_WEIGHT_GREASE_PENCIL`
Resolves#127374.
Pull Request: https://projects.blender.org/blender/blender/pulls/128604
Layer panel (also mask/ transform etc.) and other operators are gone
when properties tab is pinned and gpv3 object is non-active.
To fix this, get grease pencil pointer from `button_context()`
(done in `grease_pencil_context()`).
Continuation of cd476226d8
Pull Request: https://projects.blender.org/blender/blender/pulls/128475
Implements scrolling support for tree-views, as well as changing the size of the
scroll-able tree-view. This is important to be able to place them in many places
in the UI, where a compact layout is preferred over an every expanding one
(causing following contents to be scrolled out of view). UI-lists would use
scrolling and resizing to ensure this, now tree-views are on par.
Enables scrolling and resizing for:
- Bone collection UI (`UILayout.template_bone_collection_tree()`)
- Grease Pencil layer UI (`UILayout.template_grease_pencil_layer_tree()`)
- Light link collection UI (`UILayout.template_light_linking_collection()`)
- UI to define a node tree interface (`UILayout.template_node_tree_interface()`)
These are all cases where compact UIs make more sense than expanding ones.
Internally this is enabled by calling the `set_default_rows()` method of the
tree-view, although the API might change still. It shouldn't be quite simple to
implement this for grid-views too if necessary, or other potential view types.
Although I'd like to do some smaller code quality improvements still, this
feature is important for some other modules (e.g. grease pencil module for the
layers UI in grease pencil v3), so I decided to prioritize merging this.
Pull Request: https://projects.blender.org/blender/blender/pulls/119668
Generally increases padding of preview widgets a bit (while keeping the
preview size the same), and increases the size of the highlight surface
a bit. The default grease pencil brushes from the essentials asset
library use an opaque background, so the highlight was barely visible
before. It was difficult to identify the active brush from that. Now
it's a lot easier to identify visually.
See PR for comparison screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/128432
Customizable highlighting of editor edges that can be used to help
differentiate between areas, indicate active area, and/or help users
with visual impairment. Can be completely removed as well. This
replaces the active area header highlighting, which doesn't work for
transparent headers.
Pull Request: https://projects.blender.org/blender/blender/pulls/116684
While we continue to improve our tooltips, this PR appends a period to
descriptions if it does not already end in punctuation (.!?), or does
not contain a bullet character. This only does so under the same
circumstances as in earlier code, removed in #125460.
Pull Request: https://projects.blender.org/blender/blender/pulls/128097
This adds an eyedropper button to properties where you can choose a bone.
Clicking it activates the modal operation and you can pick:
* Bones from the Outliner
* Bones from the 3D Viewport if the Armature is in Pose Mode or Edit Mode
## Limitation
Picking from the 3D viewport while in Object Mode doesn't work due to technical reasons.
The selection buffer is only filled with pose bones if the armature is in pose mode.
Using the picker while in object mode gives you the Armature object, not its bones.
So you cannot use the bone picker to constrain an object to a bone.
UNLESS you pin the panel with the object, go to pose mode and then pick.
There is a warning printed for those cases to tell the user why this hasn't worked.
Pull Request: https://projects.blender.org/blender/blender/pulls/121523
Refactoring of the color picker popup. This simplifies code, removes
cruft, and adds new features. The Hex input is removed from its own
tab and placed at the bottom of the layout. The picker circle is made
just a bit smaller. "#" added to the hex values.
Pull Request: https://projects.blender.org/blender/blender/pulls/125675
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
lib override and add asset operation appears in nested context menu.
They are incorrectly exposed when right clicked on an operator in
context menu. So don't expose then when opening nested context menu on
operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126927
We already have the `description` property on panels but are currently not
displaying it when hovering over a panel header. With this patch, the
descriptions will be shown in group nodes as well as the geometry nodes
modifier.
I had to do two lower level changes for layout panels because it didn't work
with tooltips properly.
* Tooltips make the label in the panel header interactive, but clicking to
open/close the panel should still work.
* The tooltip should disappear when clicking on the header. This is consistent
with tooltips in other places.
Pull Request: https://projects.blender.org/blender/blender/pulls/127852
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
The function would return two very different layouts in different code
paths, making it not clear to the caller what to expect. For one code
path the return value was rather useless, and in fact unused, so I was
able to just remove this. Also clarified behavior and return values in
the function API comment.
Since 5bcb0c9935, `uiLayout.template_ID()` already supports passing a label, in
which case the `uiLayout.use_property_split` would be respected. This makes the
template fit nicely with the surrounding layout, where buttons might have a
label split on the left, and a decorator button on the right.
This change brings the same to `uiLayout.template_search()`, plus makes it
respect `uiLayout.use_property_decorate`
Pull Request: https://projects.blender.org/blender/blender/pulls/127751
Replace uses of WM_window_native_pixel_x,y with
WM_window_native_pixel_size() which returns an int2 for convenience
and avoids an unnecessary call to GHOST_GetNativePixelSize(..).
