NLA strip unexpectedly auto-switching from Hold to Hold Forward #66946

Open
opened 2019-07-15 02:20:33 +02:00 by Ovionis · 27 comments

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 770/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.64

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-12 17:50, hash: e3c586e262

When creating a new action using the HOLD_FORWARD extrapolation, frames to the left of the keyframes will keep the value of the first keyframe, instead of ignore them like they did before and do with NOTHING extrapolation. They now behave like HOLD.
They work like normal in strips, just not as the (orange) action.

nla_hold_back.blend
2019-07-14 19-08-18.mp4

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GTX 770/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.64 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-12 17:50, hash: `e3c586e262` When creating a new action using the HOLD_FORWARD extrapolation, frames to the left of the keyframes will keep the value of the first keyframe, instead of ignore them like they did before and do with NOTHING extrapolation. They now behave like HOLD. They work like normal in strips, just not as the *(orange)* action. [nla_hold_back.blend](https://archive.blender.org/developer/F7609316/nla_hold_back.blend) [2019-07-14 19-08-18.mp4](https://archive.blender.org/developer/F7609317/2019-07-14_19-08-18.mp4)
Author

Added subscriber: @Phigon

Added subscriber: @Phigon

#79577 was marked as duplicate of this issue

#79577 was marked as duplicate of this issue

Added subscriber: @mano-wii

Added subscriber: @mano-wii
Alexander Gavrilov was assigned by Germano Cavalcante 2019-07-15 21:45:58 +02:00

Regression probably introduced in 2826c2be54

Regression probably introduced in 2826c2be54

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

This is more like intentional change rather than "regression". Clipping the main action like the strips doesn't make sense, because you can't control the extents of the raw action; more importantly, it also makes the extrapolation setting of the curves largely pointless, and means that action evaluation changes just because some NLA tracks exist. If you actually check, even 'Hold' works differently - try cyclic or linear extrapolation on the action curves. 'Nothing' is preserved because it could be useful for baking out the combined result of the NLA stack, but I don't see any real use case for 'Hold Forward'.

Basically, in my view, if you want to clip, why not create a strip and use Tweak mode?

This is more like intentional change rather than "regression". Clipping the main action like the strips doesn't make sense, because you can't control the extents of the raw action; more importantly, it also makes the extrapolation setting of the curves largely pointless, and means that action evaluation changes just because some NLA tracks exist. If you actually check, even 'Hold' works differently - try cyclic or linear extrapolation on the action curves. 'Nothing' is preserved because it could be useful for baking out the combined result of the NLA stack, but I don't see any real use case for 'Hold Forward'. Basically, in my view, if you want to clip, why not create a strip and use Tweak mode?

For me it seems a valid argument.
The Hold Forward option should then be removed.

For me it seems a valid argument. The `Hold Forward` option should then be removed.
Author

@angavrilov Editing strips is fundamentally different to me.
A "raw action" lets you work free-form, with no consideration for range.

When you move it to strips, you have to specify a start/end range and if you ever want to increase it, you have to manually adjust numbers that aren't intuitive (expands only right).
Additionally sometimes you can accidentally slightly rescale a strip and then the keyframes will move to the subframes and if you don't notice it and start keyframing, you'll end up with double keyframes with SHARP transitions and have to figure out which one was the new one so you can delete the old ones, to fix the animation, and fix the strip so you can get back to animating.

Point is, I find it best to only work inside strips when you have settled on a time range and/or just making small edits.


A use case for HOLD_FORWARDis you make a pose, go back and keyframe a pose from the lower-layer animation, then you go forward animating without the previous animation overriding it for not inserting keyframes ahead.
Finally, you can go to the start of the animation, play the old animation then see it transition into the new animation.

Yes, this would be possible without HOLD_FORWARD, if you use NOTHINGand insert a keyframe far ahead in the animation
but so would it be without HOLD, if you also insert a keyframe way behind the animation.


Plus, I like for my strips to be exactly how I made them.
HOLD already doesn't work for REPLACE strips, there's no reason for HOLD_FORWARD to also not work when editing.

@angavrilov Editing strips is fundamentally different to me. A "raw action" lets you work free-form, with no consideration for range. When you move it to strips, you have to specify a start/end range and if you ever want to increase it, you have to manually adjust numbers that aren't intuitive (expands only right). Additionally sometimes you can accidentally slightly rescale a strip and then the keyframes will move to the subframes and if you don't notice it and start keyframing, you'll end up with double keyframes with SHARP transitions and have to figure out which one was the new one so you can delete the old ones, to fix the animation, and fix the strip so you can get back to animating. Point is, I find it best to only work **inside** strips when you have settled on a time range and/or just making small edits. - - - - A use case for **HOLD_FORWARD**is you make a pose, go back and keyframe a pose from the lower-layer animation, then you go forward animating without the previous animation overriding it for not inserting keyframes ahead. Finally, you can go to the start of the animation, play the old animation then see it transition into the new animation. Yes, this would be possible without **HOLD_FORWARD**, if you use **NOTHING**and insert a keyframe far ahead in the animation but so would it be without **HOLD**, if you also insert a keyframe way behind the animation. - - - Plus, I like for my strips to be exactly how I made them. **HOLD** already doesn't work for **REPLACE** strips, there's no reason for **HOLD_FORWARD** to also not work when editing.

In #66946#723971, @Phigon wrote:
A use case for HOLD_FORWARDis you make a pose, go back and keyframe a pose from the lower-layer animation, then you go forward animating without the previous animation overriding it for not inserting keyframes ahead.
Finally, you can go to the start of the animation, play the old animation then see it transition into the new animation.

I guess since it supports Nothing, it could also interpret Hold Forward as 'Nothing on the left, continue infinitely to the right'.

HOLD already doesn't work for REPLACE strips

Hm?

> In #66946#723971, @Phigon wrote: > A use case for **HOLD_FORWARD**is you make a pose, go back and keyframe a pose from the lower-layer animation, then you go forward animating without the previous animation overriding it for not inserting keyframes ahead. > Finally, you can go to the start of the animation, play the old animation then see it transition into the new animation. I guess since it supports **Nothing**, it could also interpret **Hold Forward** as '**Nothing** on the left, continue infinitely to the right'. > **HOLD** already doesn't work for **REPLACE** strips Hm?
Author

In #66946#724251, @angavrilov wrote:

In #66946#723971, @Phigon wrote:
HOLD already doesn't work for REPLACE strips

Hm?

Since I'm not making a formal report, I didn't disable my addon and etc, however what's happening here is an internal thing that's been around since even 2.7.
Basically what happens is when you move any strip inside the NLA, Blender will change the extrapolation of all REPLACE strips from HOLD to HOLD_FORWARD, except for the one most to the left.

2019-07-17 03-51-56.mp4

As I recall, the reason it happens is some sort of "intentional" thing with how the strips work or something.
I don't remember the details of "why" it's intended or if those reasons can be disregarded due to the numerous updates to the NLA in 2.8.

edit: this was the reason: #52346#451436

> In #66946#724251, @angavrilov wrote: >> In #66946#723971, @Phigon wrote: >> **HOLD** already doesn't work for **REPLACE** strips > > Hm? Since I'm not making a formal report, I didn't disable my addon and etc, however what's happening here is an internal thing that's been around since even 2.7. Basically what happens is when you move any strip inside the NLA, Blender will change the extrapolation of all REPLACE strips from HOLD to HOLD_FORWARD, except for the one most to the left. [2019-07-17 03-51-56.mp4](https://archive.blender.org/developer/F7614503/2019-07-17_03-51-56.mp4) As I recall, the reason it happens is some sort of "intentional" thing with how the strips work or something. I don't remember the details of "why" it's intended or if those reasons can be disregarded due to the numerous updates to the NLA in 2.8. edit: this was the reason: #52346#451436
Author

I have an unrelated question. is there any technical reason that strips must all have unique names per animation_data?
I found a glitch method to name multiple strips the same thing. Getting it to happen in the first place requires python trickery but once it's done, nothing breaks and everything works like normal.
2019-07-17 04-07-43.mp4

I have an unrelated question. is there any technical reason that strips must all have unique names per animation_data? I found a glitch method to name multiple strips the same thing. Getting it to happen in the first place requires python trickery but once it's done, nothing breaks and everything works like normal. [2019-07-17 04-07-43.mp4](https://archive.blender.org/developer/F7614522/2019-07-17_04-07-43.mp4)
Alexander Gavrilov was unassigned by Dalai Felinto 2019-12-23 16:33:46 +01:00

Added subscriber: @angavrilov

Added subscriber: @angavrilov

Added subscriber: @dr.sybren

Added subscriber: @dr.sybren

Changed status from 'Confirmed' to: 'Archived'

Changed status from 'Confirmed' to: 'Archived'
Sybren A. Stüvel self-assigned this 2020-02-06 17:54:12 +01:00

In #66946#724896, @Phigon wrote:
I have an unrelated question.

Please don't treat this like a forum, especially with unrelated (or loosely-related) questions. https:*devtalk.blender.org/ or https:*blender.chat/ are better places for this.

I'm closing this as a Known Issue, as the current behaviour was intended. It's also clear that things can be improved, but that's not enough to mark this as a bug. To ensure that this issue is not forgotten, I have added it to my list of weak areas of the animation system.

> In #66946#724896, @Phigon wrote: > I have an unrelated question. Please don't treat this like a forum, especially with unrelated (or loosely-related) questions. https:*devtalk.blender.org/ or https:*blender.chat/ are better places for this. I'm closing this as a Known Issue, as the current behaviour was intended. It's also clear that things can be improved, but that's not enough to mark this as a bug. To ensure that this issue is not forgotten, I have added it to my [list of weak areas of the animation system](https://wiki.blender.org/wiki/User:Sybren/Animation_Weak_Areas#NLA_Strip_extrapolation_mode).

Changed status from 'Archived' to: 'Confirmed'

Changed status from 'Archived' to: 'Confirmed'

Reopening this task so that it is easier to find. We can close it when it has been addressed.

Reopening this task so that it is easier to find. We can close it when it has been addressed.

Added subscriber: @A.Lex_3D

Added subscriber: @A.Lex_3D
Sybren A. Stüvel changed title from NLA Hold_Forward holds backwards when orange action to NLA strip unexpectedly auto-switching from Hold to Hold Forward 2020-08-06 11:13:50 +02:00
Sybren A. Stüvel removed their assignment 2020-08-18 15:48:19 +02:00
Member

Added subscriber: @wbmoss_dev

Added subscriber: @wbmoss_dev
Wayde Moss self-assigned this 2020-10-28 20:53:21 +01:00
Member

In #66946#724251, @angavrilov wrote:
I guess since it supports Nothing, it could also interpret Hold Forward as 'Nothing on the left, continue infinitely to the right'.

I agree. Having Hold_Forward be inconsistent is confusing and comes off as buggy. Does anyone have any problems if I implement this?

> In #66946#724251, @angavrilov wrote: > I guess since it supports **Nothing**, it could also interpret **Hold Forward** as '**Nothing** on the left, continue infinitely to the right'. I agree. Having Hold_Forward be inconsistent is confusing and comes off as buggy. Does anyone have any problems if I implement this?

We talked about this in yesterday's #animation_rigging module meeting. It's probably better to make the patch a little bit more "invasive", and actually remove the code that changes the user's choice in extrapolation mode (search for /* FIXME: this needs to be more automated, since user can rearrange strips */).

I think it'll be a better idea to also replace the one extrapolation option there is now with two simpler booleans:

  • Extrapolate Backward
  • Extrapolate Forward

That way the forward extrapolation can always be used, and the backward extrapolation can be greyed out in the UI when it's not considered (because it's not the first strip in the track).

We talked about this in yesterday's #animation_rigging [module meeting](https://devtalk.blender.org/t/2021-06-10-animation-rigging-module-meeting/19119). It's probably better to make the patch a little bit more "invasive", and actually remove the code that changes the user's choice in extrapolation mode (search for `/* FIXME: this needs to be more automated, since user can rearrange strips */`). I think it'll be a better idea to also replace the one extrapolation option there is now with two simpler booleans: - Extrapolate Backward - Extrapolate Forward That way the forward extrapolation can always be used, and the backward extrapolation can be greyed out in the UI when it's not considered (because it's not the first strip in the track).
Member

D10229: Fix #82234: NLA: Action Track Hold Forward Inconsistency Fixes this report's specific problem, where the Action Track treats Hold Forward that same as Hold. The pushdown extrapolation change is a different problem.
#82230 (NLA: Moving Strips Auto Changes Between Hold and Hold_Forward) Has two patches that apply the "invasive" solution:

  • D9942: NLA: Remove Hold resetting between Hold_Forward Behavior They remove the code that changes the user's extrapolation choice. They're intended to address the problem where moving strips horizontally automatically changes the extrapolation based on which appear first vertically. An example set up is of atleast a two-track, one-strip each setup.
  • D9943: NLA: Strip Evaluate Held Strips Even When Not First Strip Adds support for something similar to "Extrapolate Backward", where non-first strips with Hold will extrapolate backwards if the previous strip isn't held at all. Back then, I still couldn't think of a practical use case for backwards extrapolation even for the change in Hold behavior. This patch is more for consistency in UI, that allows you to set any strip as Hold, with what an animator would expect it to do. It's more of a "why would anyone do this? But if they did, then maybe it should do what we say it should do"..

As to whether we should add an Extrapolate Backward, given that I have not found a use case, I don't think it would improve anything for anyone. Though, I'd be happy to add the support after being given a concrete practical use case.

[D10229: Fix #82234: NLA: Action Track Hold Forward Inconsistency](https://archive.blender.org/developer/D10229) Fixes this report's specific problem, where the Action Track treats Hold Forward that same as Hold. The pushdown extrapolation change is a different problem. #82230 (NLA: Moving Strips Auto Changes Between Hold and Hold_Forward) Has two patches that apply the "invasive" solution: - [D9942: NLA: Remove Hold resetting between Hold_Forward Behavior](https://archive.blender.org/developer/D9942) They remove the code that changes the user's extrapolation choice. They're intended to address the problem where moving strips horizontally automatically changes the extrapolation based on which appear first vertically. An example set up is of atleast a two-track, one-strip each setup. - [D9943: NLA: Strip Evaluate Held Strips Even When Not First Strip](https://archive.blender.org/developer/D9943) Adds support for something similar to "Extrapolate Backward", where non-first strips with `Hold` will extrapolate backwards if the previous strip isn't held at all. Back then, I still couldn't think of a practical use case for backwards extrapolation even for the change in Hold behavior. This patch is more for consistency in UI, that allows you to set any strip as Hold, with what an animator would expect it to do. It's more of a "why would anyone do this? But if they did, then maybe it should do what we say it should do".. As to whether we should add an `Extrapolate Backward`, given that I have not found a use case, I don't think it would improve anything for anyone. Though, I'd be happy to add the support after being given a concrete practical use case.
Author

You have a motion, like maybe someone is vaulting over something and using their hand for stabilization.
You pick the frame that "should" be contacting the surface, then reposition it. Now, you go backwards to make sure the rest of the frames aren't clipping and etc.
Or maybe you want to do a slide, and you insert the first keyframe on when it needs to "stop" contacting, then animate backwards to when it started.

The reason to not use Hold/Nothing, over Hald_Backward, is the same as with Hold_Forward, just in a different direction.

You have a motion, like maybe someone is vaulting over something and using their hand for stabilization. You pick the frame that "should" be contacting the surface, then reposition it. Now, you go backwards to make sure the rest of the frames aren't clipping and etc. Or maybe you want to do a slide, and you insert the first keyframe on when it needs to "stop" contacting, then animate backwards to when it started. The reason to not use Hold/Nothing, over Hald_Backward, is the same as with Hold_Forward, just in a different direction.

I think it makes sense to use "Extrapolate Backward" also in cases where a character has some animation, but a physics system needs to just have some pre-roll before actually starting the animation. In such cases it would make sense that the character just stands still in the same pose/location as in its first animated keyframe, rather than in its rest pose/location.

I think it makes sense to use "Extrapolate Backward" also in cases where a character has some animation, but a physics system needs to just have some pre-roll before actually starting the animation. In such cases it would make sense that the character just stands still in the same pose/location as in its first animated keyframe, rather than in its rest pose/location.

Added subscriber: @ZonyZhao-2

Added subscriber: @ZonyZhao-2

Still distrubed by this. Action that changes user's behaviour quitely should not exist. I thought I haven't saved it.

Still distrubed by this. Action that changes user's behaviour quitely should not exist. I thought I haven't saved it.
Member

Added subscriber: @BClark

Added subscriber: @BClark
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:36:40 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
9 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#66946
No description provided.