Blender Git Commit Log

Feature: NLA: Evaluate Whole NLA Stack in Tweak Mode

Feature: NLA: show and evaluate whole NLA stack while in tweak mode:

**Note for reviewers**
This patch is relative to {D9247}. Apply that patch first, then apply this one afterward.

For reviewers, the two core functions changed are in anim_sys.c (BKE_animsys_nla_remap_keyframe_values and animsys_calculate_nla). I've separated the old animsys_evaluate_nla() into for_flush and for_keyframing variations to make the intent clear.

I should add that the nlastrip_evaluate() and recursive strip evaluate calls have been duplicated for inverting. They can be refactored but I've decided against it. I didn't want to refactor and add a new feature in a single patch. Keeping those calls nearly the same should make them easier to understand relative to the old implementation. I suppose I could've refactored first then made the patch, but without the duplication it could've been difficult to see the motivation for refactoring choices.

**Question**: I also noticed a UI-based confusion introduced by patch. If the animator has a nonpushed action then it has influence even while in tweak mode which is expected. However, the bounds of that influence is currently not drawn in any way while in tweak mode. It can be a surprise and source of confusion when the non-pushed action begins to influence the animation result. I should talk to the UI team about how it should be drawn. Or maybe it should be a separate patch so the UI can be developed separately given this patch is relatively big already? Should it just be part of {D7600} since that patch is close to the problem area and this one depends on it?

**Problem/Solution**
This feature solves the problem of not being able to see and consider the final animation result while tweaking a strip. Before, as a user keyframes a strip, the upper strips would be disabled. Now, the user can optionally view the upper strip affects while keyframing. The strips above it are accounted for such that the final NLA result matches what the user visually keyframed. The feature pros and cons itself sounds self explanatory but let me know if I should explain more in depth.

**Implementation**
The core implementation is that each upper strip needs to be inverted separately, solving for the blend output of the lower stack. That goes on until we have solved for the blend output of the tweaked strip and lower stack. Then we use the old existing invert math to get the fcurve value of the tweak strip. The lower stack can be inverted as a group instead of separately because we're solving for the tweak strip's value, not the lower blended value, and it doesn't include the tweaked strip.

**Changes to old behavior (Evaluating without upper stack)**
Evaluating upper stack is optional and, for now, set as default (Tab). The RClick context menu and header menu exposes the option to evaluate without the upper stack (Ctrl+Tab).

Tweaked strip no longer uses animdata->act_influence since that's used by the non-pushed action.

**Bugfixes Included Relative to Public Version **
This includes bugfixes such as evaluating meta strips correctly when next to a transition {D8287}.

**Limitations Introduced by Patch**
Keyframing through a quaternion transition of (Combine<->Replace/Add/Sub/Mul) is not handled properly and will fail to insert a keyframe. I'm still working out the math, at least for the case of (Combine<->Replace). Other quaternion transition cases should be handled properly (Combine<->Combine) and (Add/Sub/Mul/Replace <-> Add/Sub/Mul/Replace). All non-quaternion transition cases should be handled properly. This limitation only applies when such transitions appear above the tweaked strip and the upper NLA stack is enabled. Transitions that appear below the tweaked strip does not break keyframing.

**Example Files**
Location Focused:
{F8802904}
Quaternion Focused:
{F8802907}
Scale Focused:
{F8802906}

Each file has multiple objects in it that have simple NLA setups. It's just meant to save a little bit of time. Autokeying is on and keying sets match the file focus. Per check, just unhide one object at a time, enter tweak mode on the lowest strip, then try to keyframe. In most cases, your overall NLA results should be preserved when refreshing the keyframe(changing to different frame then back to the keyframed one). General failure cases include not being able to keyframe through full (influence = 1) Replace strips nor Multiply Zero strips. These are expected, mathematically there is no solution. For quaternion, an additional failure case can occur even when keyframing through a partial Replace strip. Quaternions only interpolate within 180 degrees so if the solution requires that it rotates further than 180, then the keyframe will be wrong. **(Note to self: Todo)** Current patch implementation does not properly fail on this case.

For location, it's easy to verify by using auto keying and snapping Suzanne to cursor. Refresh the frame and her origin should match the cursor. Generally, I just eyeball things and use the grid.

No specific Euler file since NLA evaluation is the same as location values. The Scale file only includes Combine strip examples since other blends modes evaluate the same as any other property, like location.

**Existing Limitations of NLA Not Solved By Patch**
If the tweaked strip's action evaluates multiple times in the same frame, then it's not solved for correctly. To support this is nontrivial. We have to allow keyframing at multiple frames and account for the different flags of each strip that uses the same action. The lower stack would have to be inverted separately just like the upper stack. Each strip may also sample the action using a different action range too.. Transitions between the linked action.. It's complicated. I expect it to be rare for the user to linked duplicate an action, overlay them stack-wise and want to keyframe.. That feature is out of scope. The attached file is a quick setup to verify the limitation. Autokeying is already on. Move the cube on the X-Axis then refresh the frame (change back to the same frame). The cube will be in a different location than keyed.
{F8883083}

Differential Revision: https://developer.blender.org/D8296