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

New Issue

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)

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)

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

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?

@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.

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:

Setting a single key on frame 3: returns (3.0, 4.0).
Setting a key on frame 3 and another key on a fractional frame 3.5: returns (3.0, 3.5).
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.

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.

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:

09a2b5c70f/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?

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?

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].

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.

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.

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:

b68b3e7b8f/source/blender/blenkernel/intern/action.c (L1466-L1469)

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.

@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).

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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

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