action.frame_range span always >=1 when there's only 1 key frame in it. #107030

Closed
opened 2023-04-17 11:27:37 +02:00 by Julien Duroure · 19 comments
Member

System Information
Operating system: Mint
Graphics card: Nvidia

Blender Version
Broken: 3.5 & main branch

Short description of error
frame_range wrong value when only 1 keyframe

Exact steps for others to reproduce the error

  • with default cube, go to frame 6
  • Insert a keyframe (for example, on location)
  • bpy.context.object.animation_data.action.frame_range returns (6.0, 7.0)

My expectation was it returns (6.0, 6.0)

If you then insert a keyframe at frame 7, it still returns (6.0, 7.0)

**System Information** Operating system: Mint Graphics card: Nvidia **Blender Version** Broken: 3.5 & main branch **Short description of error** frame_range wrong value when only 1 keyframe **Exact steps for others to reproduce the error** - with default cube, go to frame 6 - Insert a keyframe (for example, on location) - bpy.context.object.animation_data.action.frame_range returns (6.0, 7.0) My expectation was it returns (6.0, 6.0) If you then insert a keyframe at frame 7, it still returns (6.0, 7.0)
Julien Duroure added the
Severity
Normal
Type
Report
Status
Needs Triage
labels 2023-04-17 11:27:38 +02:00
Author
Member

Additional information:
bpy.context.object.animation_data.action.fcurves[0].range() returns the right result (6.0, 6.0)

Additional information: bpy.context.object.animation_data.action.fcurves[0].range() returns the right result (6.0, 6.0)
Member

I can replicate the issue with past versions as well back to 2.93.

This looks to be intentional because the NLA editor also uses this value to draw strips, this is to ensure the strip always have a valid length. Although it could be possible to return a different value for python/RNA api, and that might be better?

  /* Ensure that action is at least 1 frame long (for NLA strips to have a valid length). */
  if (*r_start >= *r_end) {
    *r_end = *r_start + 1.0f;
  }

cc @angavrilov in commit 5d59b38605

I can replicate the issue with past versions as well back to 2.93. This looks to be intentional because the NLA editor also uses this value to draw strips, this is to ensure the strip always have a valid length. Although it could be possible to return a different value for python/RNA api, and that might be better? ``` /* Ensure that action is at least 1 frame long (for NLA strips to have a valid length). */ if (*r_start >= *r_end) { *r_end = *r_start + 1.0f; } ``` cc @angavrilov in commit 5d59b38605d6
YimingWu added
Module
Animation & Rigging
Status
Needs Info from Developers
and removed
Status
Needs Triage
labels 2023-04-17 13:23:54 +02:00
YimingWu changed title from frame_range wrong value when only 1 keyframe to `action.frame_range` span always >=1 when there's only 1 key frame in it. 2023-04-17 13:25:01 +02:00

The underlying issue here I think is that D11803 is not explicit about what the numbers mean. If they represent a half-open interval [start, end) then the current behaviour is actually correct, as it just means "from 6 up to but not including frame 7". If they represent a closed interval [start, end], then the current behaviour is indeed a bug as it's off by 1.

@angavrilov as the author of D11803, could you clarify?

The underlying issue here I think is that [D11803](https://archive.blender.org/developer/D11803) is not explicit about what the numbers mean. If they represent a half-open interval `[start, end)` then the current behaviour is actually correct, as it just means "from 6 up to but not including frame 7". If they represent a closed interval `[start, end]`, then the current behaviour is indeed a bug as it's off by 1. @angavrilov as the author of D11803, could you clarify?
Member

@dr.sybren The problem with this one is that it's neither [start, end) nor [start, end], now for a frame range of [0,1] and [0,0], the length is both 1 due to minimum value clamping.

@dr.sybren The problem with this one is that it's neither `[start, end)` nor `[start, end]`, now for a frame range of [0,1] and [0,0], the length is both 1 due to minimum value clamping.
Member

If they represent a half-open interval [start, end) then the current behaviour is actually correct, as it just means "from 6 up to but not including frame 7". If they represent a closed interval [start, end], then the current behaviour is indeed a bug as it's off by 1.

Adding to what YimingWu (@ChengduLittleA) said, I did a few tests to check various cases:

  1. Setting a single key on frame 3: returns (3.0, 4.0).
  2. Setting a key on frame 3 and another key on a fractional frame 3.5: returns (3.0, 3.5).
  3. Setting a key on frame 3 and frame 4: returns (3.0, 4.0).

So it seems like the intent is to be a closed, possibly fractional interval. But a special case was perhaps added for zero-length actions for some reason. Probably(?) it makes sense to get rid of the special case here, and instead fix whatever code doesn't properly handle zero-length actions.

> If they represent a half-open interval [start, end) then the current behaviour is actually correct, as it just means "from 6 up to but not including frame 7". If they represent a closed interval [start, end], then the current behaviour is indeed a bug as it's off by 1. Adding to what YimingWu (@ChengduLittleA) said, I did a few tests to check various cases: 1. Setting a single key on frame 3: returns `(3.0, 4.0)`. 2. Setting a key on frame 3 and another key on a fractional frame 3.5: returns `(3.0, 3.5)`. 3. Setting a key on frame 3 and frame 4: returns `(3.0, 4.0)`. So it seems like the intent is to be a closed, possibly fractional interval. But a special case was perhaps added for zero-length actions for some reason. Probably(?) it makes sense to get rid of the special case here, and instead fix whatever code doesn't properly handle zero-length actions.
Member

Setting a key on frame 3 and another key on a fractional frame 3.5: returns (3.0, 3.5).

I haven't tried fractional frame, but in the case of BKE_action_get_frame_range, if we meant to get the length of at least 1 (as per comment), this also failed the assumption. There could be a case where the values are close enough but not equal, resulting in a very narrow strip.

> Setting a key on frame 3 and another key on a fractional frame 3.5: returns (3.0, 3.5). I haven't tried fractional frame, but in the case of `BKE_action_get_frame_range`, if we meant to get the length of at least 1 (as per comment), this also failed the assumption. There could be a case where the values are close enough but not equal, resulting in a very narrow strip.
Nathan Vegdahl added
Type
Design
and removed
Type
Report
labels 2023-04-21 12:38:05 +02:00
Nathan Vegdahl added this to the Animation & Rigging project 2023-04-21 12:39:28 +02:00
Member

I had a discussion with @dr.sybren, and we think that action.frame_range and BKE_action_get_frame_range simply shouldn't try to ensure that the returned interval is >= 1 at all. In other words, this bit of the code should simply be removed:

/* Ensure that action is at least 1 frame long (for NLA strips to have a valid length). */
if (*r_start >= *r_end) {
*r_end = *r_start + 1.0f;
}

The rationale being that these functions should simply return the actual range of the action/key frames, and it should be up to the calling code to ensure any invariants that they need (e.g. minimum of 1-frame length, or integer ranges, etc.).

However, this behavior has already been in Blender for about 2 years now, and changing it would be an API-breaking change that could potentially affect scripts and addons. So our proposal is to keep the current weird behavior for 3.x, and change it in 4.0.

Any thoughts on that?

I had a discussion with @dr.sybren, and we think that `action.frame_range` and `BKE_action_get_frame_range` simply shouldn't try to ensure that the returned interval is >= 1 at all. In other words, this bit of the code should simply be removed: https://projects.blender.org/blender/blender/src/commit/09a2b5c70f7607ce27eaa1f63cc359dd71b3b06e/source/blender/blenkernel/intern/action.c#L1490-L1493 The rationale being that these functions should simply return the actual range of the action/key frames, and it should be up to the calling code to ensure any invariants that they need (e.g. minimum of 1-frame length, or integer ranges, etc.). **However**, this behavior has already been in Blender for about 2 years now, and changing it would be an API-breaking change that could potentially affect scripts and addons. So our proposal is to keep the current weird behavior for 3.x, and change it in 4.0. Any thoughts on that?
Author
Member

Agree with that!

The glTF code (because I first report it because I discovered it debugging a glTF bug) has now a workaround ( using python fcurve.range() that returns the actual range values) for 3.x

This workaround will be deleted for 4.0

Agree with that! The glTF code (because I first report it because I discovered it debugging a glTF bug) has now a workaround ( using python fcurve.range() that returns the actual range values) for 3.x This workaround will be deleted for 4.0

However, this behavior has already been in Blender for about 2 years now

You are wrong here. That behavior has been there for a lot longer than 2 years, because that new code just replicates the behavior of calc_action_range. Technically it's redundant for the non-manual frame range case.

Also, regarding the intervals: for cycles they are definitely [start, end), because the end keyframe should be identical to the start one. For non-cyclic animations it's not clear, but makes sense to be [start, end].

> **However**, this behavior has already been in Blender for about 2 years now You are wrong here. That behavior has been there for a lot longer than 2 years, because that new code just replicates the behavior of `calc_action_range`. Technically it's redundant for the non-manual frame range case. Also, regarding the intervals: for cycles they are definitely [start, end), because the end keyframe should be identical to the start one. For non-cyclic animations it's not clear, but makes sense to be [start, end].
Member

You are wrong here. That behavior has been there for a lot longer than 2 years

Ah, fair enough! I should have said "for at least 2 years now". In any case, the point is the same: it's been the behavior for long enough that we should wait for 4.0 to make the change.

> You are wrong here. That behavior has been there for a lot longer than 2 years Ah, fair enough! I should have said "for *at least* 2 years now". In any case, the point is the same: it's been the behavior for long enough that we should wait for 4.0 to make the change.
Member

It appears that the consensus both here and in the animation module chat is that we should indeed go forward with the proposal. That is, remove the code that tries to ensure >= 1 frame length, but do so in 4.0, not in 3.x.

Since this won't be happening until 4.0 anyway, that gives time to collect any objections or counter-arguments. So if anyone has any, please feel free to post here.

It appears that the consensus both here and in the animation module chat is that we should indeed go forward with [the proposal](https://projects.blender.org/blender/blender/issues/107030#issuecomment-927358). That is, remove the code that tries to ensure >= 1 frame length, but do so in 4.0, not in 3.x. Since this won't be happening until 4.0 anyway, that gives time to collect any objections or counter-arguments. So if anyone has any, please feel free to post here.
Member

As @angavrilov pointed out, this was the behavior before the code in question was written. And in particular, that previous code still exists and is also still in use here:

/* ensure that action is at least 1 frame long (for NLA strips to have a valid length) */
if (min == max) {
max += 1.0f;
}

So we'll want to change that as well.

As @angavrilov pointed out, this was the behavior before the code in question was written. And in particular, that previous code still exists and is also still in use here: https://projects.blender.org/blender/blender/src/commit/b68b3e7b8f4cd24a286e0ec320445b9d7bf71fea/source/blender/blenkernel/intern/action.c#L1466-L1469 So we'll want to change that as well.

However, this behavior has already been in Blender for about 2 years now

You are wrong here. That behavior has been there for a lot longer than 2 years, because that new code just replicates the behavior of calc_action_range. Technically it's redundant for the non-manual frame range case.

@angavrilov @cessen Could either of you take a look at this duplication in both locations? Having duplicated code can be ok in certain cases, but if the behaviour of both is intended to be the same, that's easier to ensure when they share the same function for it. If that's not possible, please at least add a note at each duplication site that informs the reader of the other one.

> > **However**, this behavior has already been in Blender for about 2 years now > > You are wrong here. That behavior has been there for a lot longer than 2 years, because that new code just replicates the behavior of `calc_action_range`. Technically it's redundant for the non-manual frame range case. @angavrilov @cessen Could either of you take a look at this duplication in both locations? Having duplicated code can be ok in certain cases, but if the behaviour of both is intended to be the same, that's easier to ensure when they share the same function for it. If that's not possible, please at least add a note at each duplication site that informs the reader of the other one.
Sybren A. Stüvel added this to the 4.0 milestone 2023-05-04 09:22:55 +02:00
Sybren A. Stüvel added
Status
Confirmed
and removed
Status
Needs Info from Developers
labels 2023-05-04 09:23:42 +02:00
Sybren A. Stüvel removed this from the Animation & Rigging project 2023-05-04 09:23:55 +02:00
Member

@dr.sybren Yeah, I was assuming we'd probably combine them as part of the change for 4.0 (after checking that it makes sense). But I failed to mention that in my comment.

Do you want to bump that bit up, and do just the de-duplication (if it makes sense) now?

@dr.sybren Yeah, I was assuming we'd probably combine them as part of the change for 4.0 (after checking that it makes sense). But I failed to mention that in my comment. Do you want to bump that bit up, and do just the de-duplication (if it makes sense) now?

Nah, let's do both in one go. There's no need to dive further into the code now to do one thing, then let the knowledge sink into the background before making yet another adjustment. Just make sure it's two separate commits (potentially separate PRs).

Nah, let's do both in one go. There's no need to dive further into the code now to do one thing, then let the knowledge sink into the background before making yet another adjustment. Just make sure it's two separate commits (potentially separate PRs).
Author
Member

This change was tag as 4.0 because of breaking change.
Is it still planned?

This change was tag as 4.0 because of breaking change. Is it still planned?
Member

To me it seems reasonable to change it in 4.0. Current +1 frame behaviour looks fine on the UI but it's unlogical in the context of coding.

To me it seems reasonable to change it in 4.0. Current `+1 frame` behaviour looks fine on the UI but it's unlogical in the context of coding.
Member

Yes, I think we should still do this for 4.0. It kind of fell through the cracks. I'll add it to my todo.

Yes, I think we should still do this for 4.0. It kind of fell through the cracks. I'll add it to my todo.
Nathan Vegdahl self-assigned this 2023-08-24 15:06:37 +02:00
Member

I've been implementing the fix for this, and it's taken me down a rabbit hole that I didn't expect. Here's what I've learned (bear with me, because at first it won't sound relevant):

There's a relationship that the NLA system tries to enforce between all of the following NLA strip properties: the strip start/end, the strip's clip start/end, and the strip's clip scale and repeat. Basically, the strip's length must always equal its clip length * clip scale * clip repeat.

There are a bunch of goofy effects from this. For example, this relationship is maintained differently depending on which property you edit. If you edit the strip start/end, the code automaticlly changes the clip start/end to keep the relationship. But if you edit the clip scale or repeat, it edits the strip start/end to maintain the relationship. On the face of it that's reasonable-ish, except that there are other invariants that only get maintained when editing specific properties directly. For example, strips are apparently supposed to have a minimum length of 0.1, but that is only enforced when editing the strip start/end, not when editing the e.g. the clip start/end or scale. So you can easily force a strip to have a length of 0.0001 by manipulating those other properties. But then if you edit the strip start/end again, it pops back to the minimum 0.1.

Anyway, here's why this is relevant to this issue: one of the other goofy effects from this is that if the clip length (not the strip length) is zero, then to maintain the aforementioned relationship between all of these properties the scale would then have to be infinity. To side-step this, in some "strategic" places (but not all places) the clip length is conditionally defined to be 1.0 whenever it would otherwise be 0.0. And one of those strategic places is BKE_action_get_frame_range, which also happens to be the C function that's called by action.frame_range in the Python API. Which is why it also has that behavior.

In short, it's a big mess. I started pulling at this thread, thinking I'd fix things up along the way. But as described above, it's bigger and more tangled than I anticipated. So I'm now going back to the much narrower fix just for this issue, although I still need to be careful to dodge the scale=infinity case in the NLA code. I plan to wrap this up tomorrow.

I've been implementing the fix for this, and it's taken me down a rabbit hole that I didn't expect. Here's what I've learned (bear with me, because at first it won't sound relevant): There's a relationship that the NLA system tries to enforce between all of the following NLA strip properties: the strip `start`/`end`, the strip's clip `start`/`end`, and the strip's clip `scale` and `repeat`. Basically, the strip's length must always equal its clip length * clip scale * clip repeat. There are a bunch of goofy effects from this. For example, this relationship is maintained differently depending on which property you edit. If you edit the strip start/end, the code automaticlly changes the clip start/end to keep the relationship. But if you edit the clip scale or repeat, it edits the strip start/end to maintain the relationship. On the face of it that's reasonable-ish, except that there are *other* invariants that only get maintained when editing specific properties directly. For example, strips are apparently supposed to have a minimum length of 0.1, but that is only enforced when editing the strip start/end, not when editing the e.g. the clip start/end or scale. So you can easily force a strip to have a length of 0.0001 by manipulating those other properties. But then if you edit the strip start/end again, it pops back to the minimum 0.1. Anyway, here's why this is relevant to this issue: one of the other goofy effects from this is that if the clip length (not the strip length) is zero, then to maintain the aforementioned relationship between all of these properties the scale would then have to be infinity. To side-step this, in some "strategic" places (but not all places) the clip length is conditionally defined to be 1.0 whenever it would otherwise be 0.0. And one of those strategic places is `BKE_action_get_frame_range`, which also happens to be the C function that's called by `action.frame_range` in the Python API. Which is why it also has that behavior. In short, it's a big mess. I started pulling at this thread, thinking I'd fix things up along the way. But as described above, it's bigger and more tangled than I anticipated. So I'm now going back to the much narrower fix just for this issue, although I still need to be careful to dodge the scale=infinity case in the NLA code. I plan to wrap this up tomorrow.
Blender Bot added
Status
Resolved
and removed
Status
Confirmed
labels 2023-09-26 18:19:09 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
5 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#107030
No description provided.