NLA: Moving Strips Auto Changes Between Hold and Hold_Forward #82230

Open
opened 2020-10-29 19:11:28 +01:00 by Wayde Moss · 4 comments
Member

Bug Report #42808 (NLA: Moving one strip resets extrapolation on other strip) #45854 (Hold forward is reseted in NLA)

Source of Problem: #42808#843296

Solution: I think the code enforcing this can be removed. I don't think this restriction was ever necessary. When an animator uses a Full Replace Hold strip above other strips, it's expected behavior that it occludes the lower strips. That's what a Full Replace strip is supposed to do. Full means strip influence = 1. For consistency, we'll have to add support when a strip has extrapolation None leading to a strip with Hold. We'll also have to add support for Hold_Backwards extrapolation for completeness. In the case of conflicting adjacent strips (Hold into a Hold), we let the first strip have priority which leads to the next strip as behaving as Hold_Forward.

Potential Problems with Solution:

  • When two adjacent strips have Hold extrapolation, which should evaluate? It seems natural to let only the preceding strip evaluate.
  • When a strip has Hold_Forwards extrapolation and the next has Hold_Backwards, which should evaluate? Here, I think we should still let only the preceding strip evaluate, for consistency with the previous point.

Implementation/Patches
D9942: NLA: Remove Hold resetting between Hold_Forward Behavior
D9943: NLA: Strip Evaluate Held Strips Even When Not First Strip (depends on previous patch)
(todo) Patch3: Add Hold_Backwards support. Unsure about whether this is actually useful. Maybe we should wait till there is a concrete use-case for it?

Bug Report #42808 (NLA: Moving one strip resets extrapolation on other strip) #45854 (Hold forward is reseted in NLA) **Source of Problem**: #42808#843296 **Solution:** I think the code enforcing this can be removed. I don't think this restriction was ever necessary. When an animator uses a Full Replace Hold strip above other strips, it's expected behavior that it occludes the lower strips. That's what a Full Replace strip is supposed to do. Full means strip influence = 1. For consistency, we'll have to add support when a strip has extrapolation `None` leading to a strip with `Hold`. We'll also have to add support for `Hold_Backwards` extrapolation for completeness. In the case of conflicting adjacent strips (`Hold` into a `Hold`), we let the first strip have priority which leads to the next strip as behaving as `Hold_Forward`. **Potential Problems with Solution:** - When two adjacent strips have `Hold` extrapolation, which should evaluate? It seems natural to let only the preceding strip evaluate. - When a strip has `Hold_Forwards` extrapolation and the next has `Hold_Backwards`, which should evaluate? Here, I think we should still let only the preceding strip evaluate, for consistency with the previous point. ____ **Implementation/Patches** [D9942: NLA: Remove Hold resetting between Hold_Forward Behavior](https://archive.blender.org/developer/D9942) [D9943: NLA: Strip Evaluate Held Strips Even When Not First Strip](https://archive.blender.org/developer/D9943) (depends on previous patch) (todo) Patch3: Add `Hold_Backwards` support. Unsure about whether this is actually useful. Maybe we should wait till there is a concrete use-case for it?
Author
Member

Added subscriber: @wbmoss_dev

Added subscriber: @wbmoss_dev
Author
Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Member

Added subscriber: @BClark

Added subscriber: @BClark

This issue was referenced by 63d2980efa

This issue was referenced by 63d2980efa2fb170b471e4905ec81cd1472e5268
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:36:08 +01:00
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#82230
No description provided.