| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Introduced by my recent commit: {rB3acbe2d1e933}
Lead to crash when insert_keyframe_direct() was called. Keyframing
crashed for NLA special properties (influence, animated_time),
driven properties, etc.
|
|
Add a new operator, "Start Tweaking Strip Actions (Full Stack)", which
allows you to insert keyframes and preserve the pose that you visually
keyed while upper strips are evaluating,
The old operator has been renamed from "Start Tweaking Strip Actions" to
"Start Tweaking Strip Actions (Lower Stack)" and remains the default for
the hotkey {key TAB}.
**Limitations, Keyframe Remapping Failure Cases**:
1. For *transitions* above the tweaked strip, keyframe remapping will
fail for channel values that are affected by the transition. A work
around is to tweak the active strip without evaluating the upper NLA
stack.
It's not supported because it's non-trivial and I couldn't figure it
out for all transition combinations of blend modes. In the future, it
would be nice if transitions (and metas) supported nested tracks
instead of using the left/right strips for the transitions. That
would allow the transitioned strips to overlap in time. It would also
allow N strips to be part of the (previously) left and right strips,
or perhaps even N strips being transitioned in sequence (similar to a
blend tree). Proper keyframe remapping through all that is currently
beyond my mathematical ability. And even if I could figure it out,
would it make sense to keyframe remap through a transition?
//This case is reported to the user for failed keyframe insertions.//
2. Full replace upper strip that contains the keyed channels.
//This case is reported to the user for failed keyframe insertions.//
3. When the same action clip occurs multiple times (colored Red to
denote it's a linked strip) and vertically overlaps the tweaked
strip, then the remapping will generally fail and is expected to
fail.
I don't plan on adding support for this case as it's also non-trivial
and (hopefully) not a common or expected use case so it shouldn't be
much of an issue to lack support here.
For anyone curious on the cases that would work, it works when the
linked strips aren't time-aligned and when we can insert a keyframe
into the tweaked strip without modifying the current frame output of
the other linked strips. Having all frames sampled and the strip
non-time aligned leads to a working case. But if all key handles are
AUTO, then it's likely to fail.
//This case is not reported to the user for failed keyframe
insertions.//
4. When using Quaternions and a small strip influence on the tweaked
Combine strip. This was an existing failure case before this patch
too but worth a mention in case it causes confusion. D10504 has an
example file with instructions.
//This case is not reported to the user for failed keyframe insertions. //
5. When an upper Replace strip with high influence and animator keys to
Quaternion Combine (Replace is fine). This case is similar to (4)
where Quaternion 180 degree rotation limitations prevent a solution.
//This case is not reported to the user for failed keyframe insertions.//
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D10504
|
|
It was not possible to assign a shortcut to menu items in the insert
key-frame menu going back to version 2.7x. Doing so would replace the
current key that opens the insert keyframe menu (I-key by default),
instead of binding a key to insert a key-frame for the keying-set
referenced by the menu item.
Now each menu item can be bound to a key or added to the "Quick
Favorites" menu, directly inserting a key-frame for the corresponding
keying-set.
Note that users must use the operator `anim.keyframe_insert_by_name`
when setting up key-shortcuts as `anim.keyframe_insert` is only intended
to launch the menu.
Keymap Editor:
When editing these key-map items in the key-map editor, the keying-set
identifier must be used. At the moment the key-map editor doesn't
support showing a drop-down list. The identifiers can be used from the
tool-tip or the info editor.
{F12994924}
Details:
Use `ANIM_OT_keyframe_insert_by_name` instead of
`ANIM_OT_keyframe_insert_menu` for the insert keyframe popup menu to
resolve the following issues binding keys to keying sets:
- The index of the keying set isn't stable (adding/removing keying sets
may change it).
- Binding a key to items in the popup menu triggers a popup instead of
inserting a key using the keying set from the menu item.
While support for using the current operator could be improved, it will
still only work for built-in keying sets, so I'd prefer to use an
operator that is intended for key-bindings.
Besides supporting binding keys to menu items there are no functional
changes.
Reviewed By: sybren
Ref D14289
|
|
So far it was needed to declare a new RNA struct to `RNA_access.h` manually.
Since 9b298cf3dbec we generate a `RNA_prototypes.h` for RNA property
declarations. Now this also includes the RNA struct declarations, so they don't
have to be added manually anymore.
Differential Revision: https://developer.blender.org/D13862
Reviewed by: brecht, campbellbarton
|
|
|
|
|
|
Pass NULL instead of an empty string.
|
|
Error in 1a12c9edab4ac89c8a87c20ad3a2195d0e681bc8,
also correct descriptions.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Also ensure space at end of comment.
|
|
Some doc-strings were skipped because of blank-lines between
the doc-string and the symbol and needed to be moved manually.
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
Ref T92709
|
|
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
|
|
|
|
By argument naming and convention this is the intended argument order.
|
|
Following operators now only report messages back when they are called via their invoke-methods:
- ANIM_OT_keyframe_insert
- ANIM_OT_keyframe_insert_by_name
- ANIM_OT_keyframe_insert_menu
- ANIM_OT_keyframe_delete
- ANIM_OT_keyframe_clear_v3d
- ANIM_OT_keyframe_delete_v3d
Also removed the attribute confirm_success from the following operators:
- ANIM_OT_keyframe_insert
- ANIM_OT_keyframe_insert_by_name
- ANIM_OT_keyframe_insert_menu
- ANIM_OT_keyframe_delete
- ANIM_OT_keyframe_delete_by_name
Note: addons/scripts possibly need to be updated if they use the above operators AND set the "confirm_success" attribute
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12697
|
|
The issues:
1.) When we want to remove keyframes from a range of frames in an
action,
then we can use bpy.ops.anim.keyframe_delete_v3d to remove the keys
frame by frame. However, whenever the operator hits a frame with no
keyframes, then it generates an error. While when it hits a frame
with keyframes, then it reports the numbner of removed keys.
This creates a lot of unnecessary noise in the Blender console.
2.) Furthermore a related issue is that WM_event_add_notifier() is
called also when no frames where removed. This seems to significantly
slow down the removal of keyframes in a range of frames at least
when i use vscode for debugging.
A proposal for improvement:
This patch adds an attribute 'confirm_success' which controls
if the operator reports back what it did (or did not) while
executing. Silent mode would then be called like this:
bpy.ops.anim.keyframe_delete_v3d(confirm_success=False)
Note: confirm_success is True by default so this patchj does not
change the behavior of Blender, it only gives the option to scripts.
3.) Personal note:
I have chosen the attribute name to be equal as it is used
in other related operators. However i rather would rename the
attribute to "verbose" (preferred) or "with_confirm". But i let this
to be decided by the reviewers. Thanks for your time to review!
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12629
|
|
Support extracting identifiers RNA paths into fixed size buffer
since the maximum size of the identifier is known all cases.
- Add BLI_str_unescape_ex to support limiting the destination buffer.
- Add BLI_str_quoted_substr to copy values into a fixed size buffer.
|
|
Rely on BLI_str_quoted_substrN to detect if the prefix exists since
this function exists early there is no need to check before calling.
|
|
Use the term `ensure` as existing data is used when present.
|
|
Partially revert 7fc220517f87a2c40a4f438a50485233ae6ed62f, as it
introduced two issues:
- Deleting keys without active keying set was no longer possible, and
- there was no more confirmation popup.
Pressing {key Alt I} in the 3D Viewport now executes
`ANIM_OT_keyframe_delete_v3d`, adjusted to suit both T88068 and T89592:
- If there is an active keying set, delete keys according to that keying
set.
- Otherwise, behave as `ANIM_OT_keyframe_delete_v3d` did before, that
is, delete all keyframes of the selected object and in pose-mode also
of selected bones.
|
|
Remove duplicate code from the `ANIM_OT_keyframe_delete` operator. The
actions of the removed code are already performed by the preceding
`keyingset_get_from_op_with_error()` call.
No functional changes.
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
|
|
|
|
|
|
Remove the `BONE_UNKEYED` flag. It was only written (set/cleared) but
never actually read.
Also remove `framechange_poses_clear_unkeyed()` as its only function was
to clear the `BONE_UNKEYED` flag. It wasn't used anywhere either.
The only code that used the flag was the `extract_pose_from_action()`,
which was removed in 2869ce6cfab3aa4ff471bef6e49ac6fe15426247 (2009).
No functional changes.
|
|
|
|
|
|
No intended functional changes.
Refactors animsys_evaluate_nla() into 2 versions:
animsys_evaluate_nla_for_keyframing(), animsys_evaluate_nla_for_flush()
to make it clear what data is being calculated and why.
Dummy strip creation has been refactored to two separate functions,
animsys_create_tweak_strip() and animsys_create_action_track_strip().
Both are evaluated differently from other strips and eachother. There's
no need to interweave them. A future patch D8296, generally requires
both strips.
___
XXX anim_sys.c) nlatrack_find_tweaked() is a temporary work around.
If anyone has any insight into this problem, help is appreciated.
Reviewed by: sybren
Differential Revision: http://developer.blender.org/D9696
|
|
This was returning an empty allocated string, however almost
all callers checked if the return value was NULL before freeing,
making for misunderstandings on the intended use of this function.
BCAnimationSampler::initialize_curves for example detected the
f-curves animation type to 'bone' based on a non-NULL return value
which never failed.
Also fixes two leaks where the the result of BLI_str_quoted_substrN
wasn't freed.
|
|
In cases where "Allow" is followed by an infinitive, a noun needs
to directly follow it. But it makes more sense to follow it with a
gerund instead.
|
|
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
|
|
Check selection state in `BKE_fcurve_active_keyframe_index()`, and only
return the active keyframe index when that keyframe is actually selected.
This is now also asserted in the `BKE_fcurve_active_keyframe_set()` function,
which is now also used when inserting a keyframe.
|
|
Previously Blender would only match the existing curve slope when the
to-be-inserted key value was already very close to the curve. This check
is now removed, allowing for sliders in the graph editor to subtly
change the curve, and for keyframes added with ctrl+click to follow the
curve better.
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
In the graph editor there is a panel that says "Active Keyframe" for
numerically editing a keyframe's values, but in the code there is no
concept of the "active keyframe." Since this is a useful concept to
have for some other features anyway, this commit adds an active
keyframe index value to FCurves. It also displays it with a theme
color for the active vertex (which didn't exist before) if the
FCurve is active.
The active keyframe in the graph editor is treated similarly to the
active vertex in the 3D view. It is the keyframe most recently selected
with a single click, and it is always selected.
For now, the only real functional change is that the active keyframe
appears in white and it should be more predictable which keyframe is
being edited in the sidebar panel.
Differential Revision: https://developer.blender.org/D7737
|
|
Apply the De Casteljau algorithm to split the Bèzier curve at the X
coordinate where the new key is inserted, and uses the result to update
both the newly inserted and surrounding handles.
For curves that use Auto keyframes this has been largely addressed by
the new algorithm from D2884. This commit extends this to non-auto
handles.
This code is heavily based on D3172 by Alexander Gavrilov (@angavrilov).
Manifest Task: https://developer.blender.org/T81353
|
|
Actions are either locked to a specific ID type, or "floating". Actions
in the floating state are now locked when they are assigned to an ID block.
Previously (rB94b99b5d4a7c20cf2) this was done at evaluation time, which
caused various problems:
- The ID type was set on the evaluated copy, and inconsistently flushed
back to the original.
- A newly created Action could not be assigned to an Action constraint,
unless a depsgraph evaluation was be forced first.
This is now resolved by calling `BKE_animdata_set_action()` to set the
action (instead of direct assignment) where possible, and calling
`BKE_animdata_action_ensure_idroot()` otherwise.
Manifest Task: https://developer.blender.org/T80986
|
|
A parameter was added during development, but it was not needed and was
never removed. No functional changes.
|
|
Add an option to only draw icons for operator_enum menus. This is used
for drawing inline icon buttons in the outliner context menu for
collection color tagging.
Part of T77408
Differential Revision: https://developer.blender.org/D8880
|
|
|
|
Caused by rBfffba2b6530.
In above commit, the buttons rnaindex [-1 for entire arrays like colors]
was not used anymore for the entire function body of
`ED_autokeyframe_property` (previously in `ui_but_anim_autokey`).
Replacing the index with 0 (in the array case) is indeed necessary for
`BKE_fcurve_find_by_rna_context_ui`, prior to rBfffba2b6530 this was
taken care of by using `ui_but_get_fcurve` instead [which did this
internally].
But using an index of 0 (instead of -1) for the entire function body of
`ED_autokeyframe_property` fails for the array part later, namely
`insert_keyframe` needs -1 here.
Now just replace the index for //finding the FCurve//, but use the
original for //inserting the keyframe//.
Could be backported to 2.83 LTS.
Reviewers: campbellbarton, sybren
Subscribers:
|
|
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/animation` module.
No functional changes.
|
|
|
|
|
|
Functionality here has become confusing over time,
this removes duplicate, similar functions, preferring to set the mode
instead of toggle, enter, exit.
Mode switching utility function behaved differently regarding undo,
'ED_object_mode_toggle' for example didn't skip the undo push
where 'ED_object_mode_set' did.
Some callers chose these functions based on the intended undo behavior,
even when toggling didn't make sense.
There was also ED_object_mode_generic_enter which was similar to
ED_object_mode_set, instead of the reverse of ED_object_mode_generic_exit.
Simplify object mode switching internals:
- Replace ED_object_mode_generic_enter with ED_object_mode_set.
- Remove ED_object_mode_toggle as nearly all callers needed to check
the current mode so toggling would set the mode argument correctly.
- Use ED_object_mode_set for the object mode switching operator
to simplify logic.
- Add ED_object_mode_set_ex which has an argument to disable undo,
needed when loading undo data needs to set the mode.
- Remove unused ED_object_mode_exit.
|
|
All the driver-specific code in `fcurve.c` has been moved into a new file
`fcurve_driver.c`. The corresponding declarations have been moved from
`BKE_fcurve.h` to `BKE_fcurve_driver.h`.
All the `#include "BKE_fcurve.h"` statements have been investigated and
replaced with `BKE_fcurve_driver.h` where necessary.
No functional changes.
|
