NLA strip unexpectedly auto-switching from Hold to Hold Forward #66946
Labels
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#66946
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Added subscriber: @Phigon
#79577 was marked as duplicate of this issue
Added subscriber: @mano-wii
Regression probably introduced in
2826c2be54
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?
For me it seems a valid argument.
The
Hold Forward
option should then be removed.@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.
I guess since it supports Nothing, it could also interpret Hold Forward as 'Nothing on the left, continue infinitely to the right'.
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
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
Added subscriber: @angavrilov
Added subscriber: @dr.sybren
Changed status from 'Confirmed' to: 'Archived'
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.
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.
Added subscriber: @A.Lex_3D
NLA Hold_Forward holds backwards when orange actionto NLA strip unexpectedly auto-switching from Hold to Hold ForwardAdded subscriber: @wbmoss_dev
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:
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).
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:
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.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.
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.
Added subscriber: @BClark