Page MenuHome

NLA Hold_Forward holds backwards when orange action
Closed, InvalidPublicKNOWN ISSUE

Description

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: rBe3c586e262dd

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.


Event Timeline

Germano Cavalcante (mano-wii) lowered the priority of this task from 90 to 50.Jul 15 2019, 9:21 PM

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.

@Alexander Gavrilov (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.

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?

Ovionis (Phigon) added a comment.EditedJul 17 2019, 11:06 AM

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.

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: T52346#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.

Sybren A. Stüvel (sybren) claimed this task.
Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Known Issue".

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.