NLA: Moving one strip resets extrapolation on other strip #42808

New Issue

Georg Wieser · 2014-12-05T17:08:40+01:00

Georg Wieser commented

2014-12-05 17:08:40 +01:00

System Information
OSX 10.8.5, nvidia GTX 580

Blender Version
2.72b

Short description of error
Some (for example moving a strip to another track) operations in the NLA editor reset extrapolatio back to "hold forward"

Exact steps for others to reproduce the error

open Blender
create object
on that object, create 2 NLA strips and 3 Tracks
set one NLA strip's extrapolation mode to "hold" (not on "animation data", on "active strip", in the N-panel)
select the other NLA strip and move it to the track above or below (does not need to be to or from the same track as the first strip)
extrapolation mode on the first strip resets back to "hold forward"NLA_bug.blend

**System Information** OSX 10.8.5, nvidia GTX 580 **Blender Version** 2.72b **Short description of error** Some (for example moving a strip to another track) operations in the NLA editor reset extrapolatio back to "hold forward" **Exact steps for others to reproduce the error** - open Blender - create object - on that object, create 2 NLA strips and 3 Tracks - set one NLA strip's extrapolation mode to "hold" (not on "animation data", on "active strip", in the N-panel) - select the other NLA strip and move it to the track above or below (does not need to be to or from the same track as the first strip) - extrapolation mode on the first strip resets back to "hold forward"[NLA_bug.blend](https://archive.blender.org/developer/F129322/NLA_bug.blend)

Georg Wieser commented

2014-12-05 17:08:40 +01:00

Changed status to: 'Open'

Georg Wieser commented

2014-12-05 17:08:40 +01:00

Added subscriber: @sharky0815

Joshua Leung self-assigned this 2014-12-06 00:40:21 +01:00

Julian Eisel commented

2014-12-06 01:29:56 +01:00

Added subscriber: @JulianEisel

Marc Dittmar commented

2016-10-12 11:27:28 +02:00

Added subscriber: @marc_von_step

Joshua Leung was unassigned by Dalai Felinto

2019-12-23 16:37:59 +01:00

Sybren A. Stüvel commented

2020-01-06 15:32:40 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-01-06 15:32:40 +01:00

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

2020-01-06 15:32:40 +01:00

Sybren A. Stüvel self-assigned this 2020-01-06 15:32:40 +01:00

Sybren A. Stüvel commented

2020-01-06 15:32:40 +01:00

Unable to reproduce with current master (2.82, 7213c42b6e), so probably already fixed.

Unable to reproduce with current master (2.82, 7213c42b6e), so probably already fixed.

Marc Dittmar commented

2020-01-06 15:56:03 +01:00

Thanks for looking into the longstanding issue.
I just checked with a fresh build 2.82(e993667a46) and can still reproduce:
Blender 2020-01-06 15-47-49.mp4

Thanks for looking into the longstanding issue. I just checked with a fresh build 2.82(e993667a46c2) and can still reproduce: [Blender 2020-01-06 15-47-49.mp4](https://archive.blender.org/developer/F8262369/Blender_2020-01-06_15-47-49.mp4)

Sybren A. Stüvel commented

2020-01-07 10:29:53 +01:00

Changed status from 'Archived' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

2020-01-07 10:29:53 +01:00

Sybren A. Stüvel commented

2020-01-07 10:55:34 +01:00

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

2020-01-07 10:55:34 +01:00

Sybren A. Stüvel commented

2020-01-07 10:55:34 +01:00

I did some more digging, and this behaviour is by design. According to BKE_nla_validate_state() in nla.c, only the first NLA Strip can be set to Extrapolation Mode: Hold. However, this is not documented in the manual (I'll fix that soon), and this is only enforced after moving a strip, which makes its behaviour appear like a bug.

I have noted this issue on my Weak Areas of Animation page so that we don't forget about this.

I did some more digging, and this behaviour is by design. According to `BKE_nla_validate_state()` in `nla.c`, only the first NLA Strip can be set to Extrapolation Mode: Hold. However, this is not documented in the manual (I'll fix that soon), and this is only enforced after moving a strip, which makes its behaviour appear like a bug. I have noted this issue on [my Weak Areas of Animation](https://wiki.blender.org/wiki/User:Sybren/Animation_Weak_Areas#NLA_Strip_extrapolation_mode) page so that we don't forget about this.

Wayde Moss commented

2020-10-28 19:08:17 +01:00

Added subscriber: @wbmoss_dev

Wayde Moss commented

2020-10-28 19:08:17 +01:00

In #42808#843296, @dr.sybren wrote:
I did some more digging, and this behaviour is by design. According to BKE_nla_validate_state() in nla.c, only the first NLA Strip can be set to Extrapolation Mode: Hold.

Even though this is intentional. ( commit https:*developer.blender.org/rBS0f4fd4f5b17d4fff97cc3cde4cc7d144137154ca ) ( reason: https:*developer.blender.org/T29869#147024 ). Despite that, I don't think it was ever necessary. When the 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.

If implemented, then non-first strips will be able to have Hold extrapolation. That leads to the situation of two strips, the first with Hold or Hold_Forward, the next with Hold. Which should evaluate? I think it's natural to let the first strip evaluate. We would also have to add proper support for when the previous strip's extrapolation is None and the next is Hold.

> In #42808#843296, @dr.sybren wrote: > I did some more digging, and this behaviour is by design. According to `BKE_nla_validate_state()` in `nla.c`, only the first NLA Strip can be set to Extrapolation Mode: Hold. Even though this is intentional. ( commit https:*developer.blender.org/rBS0f4fd4f5b17d4fff97cc3cde4cc7d144137154ca ) ( reason: https:*developer.blender.org/T29869#147024 ). Despite that, I don't think it was ever necessary. When the 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. If implemented, then non-first strips will be able to have Hold extrapolation. That leads to the situation of two strips, the first with Hold or Hold_Forward, the next with Hold. Which should evaluate? I think it's natural to let the first strip evaluate. We would also have to add proper support for when the previous strip's extrapolation is None and the next is Hold.

Brad Clark commented

2022-01-31 21:07:05 +01:00

Added subscriber: @BClark

Brad Clark commented

2022-01-31 21:07:05 +01:00

Adding a note here to make a test file and case around this but the base idea would be to remove this limitation/behavior and also remove the "transition" tool and instead allow the hold type actions to be able to mix and auto create a blended or interpolation transition. Simplifying workflows and also making it easier to drag and drop action clips/strips around.

Brad Clark commented

2022-02-01 06:30:15 +01:00

The real problem is that HOLD only works on the "First Clip" meaning that if one clip is dragged before the other clips in the timeline, it automatically switches to HOLD fro Hold Froward...back and forth, there can be only one!!!

Blender code that changes over and over again without warning, what the animator has chosen is wrong.

Situation one:
Animator has one action and sets it to hold, hold forward or nothing, these settings stay and don't change.

Situation two:
Animator has two actions, one set to nothing, one set to hold.. as soon as the action that is set to HOLD moves past the start of the second action set to nothing, the HOLD setting switches to Hold forward, drag it back to start first, now it is set to HOLD, no matter what the user picked... it stays as long as they don't touch anything but the one set to nothing for extrapolation, stays as nothing. So not only do we have an automated override of the user setting, it isn't consistent since "nothing" setting stays as it was set.

Situation three:
Animator has many actions, all adjusted and the settings as they want, some layer actions are set to hold forward, some are set to hold (even though they are not the very FIRST clip in time before all other clips) and then everything stays exactly as the animator/user set and is fine. Until one clip is moved now all the actions that had been set to HOLD (lets say 4 or 5 ) have now been switched to HOLD FORWARD, all of them, everything changes by moving any one clip...silently messing up all the settings across all the clips the user setup exactly how they wanted.

This is a very big problem.

The real problem is that HOLD only works on the "First Clip" meaning that if one clip is dragged before the other clips in the timeline, it automatically switches to HOLD fro Hold Froward...back and forth, there can be only one!!! Blender code that changes over and over again without warning, what the animator has chosen is wrong. **Situation one:** Animator has one action and sets it to hold, hold forward or nothing, these settings stay and don't change. **Situation two:** Animator has two actions, one set to nothing, one set to hold.. as soon as the action that is set to HOLD moves past the start of the second action set to nothing, the HOLD setting switches to Hold forward, drag it back to start first, now it is set to HOLD, no matter what the user picked... it stays as long as they don't touch anything but the one set to nothing for extrapolation, stays as nothing. So not only do we have an automated override of the user setting, it isn't consistent since "nothing" setting stays as it was set. **Situation three:** Animator has many actions, all adjusted and the settings as they want, some layer actions are set to hold forward, some are set to hold (even though they are not the very FIRST clip in time before all other clips) and then everything stays exactly as the animator/user set and is fine. Until one clip is moved now all the actions that had been set to HOLD (lets say 4 or 5 ) have now been switched to HOLD FORWARD, all of them, everything changes by moving any one clip...silently messing up all the settings across all the clips the user setup exactly how they wanted. This is a very big problem.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

NLA: Moving one strip resets extrapolation on other strip #42808