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

New Issue

Julien DUROURE · 2023-04-17T11:27:37+02:00

Julien DUROURE commented

2023-04-17 11:27:37 +02:00

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

labels 2023-04-17 11:27:38 +02:00

Julien DUROURE commented

2023-04-17 11:40:32 +02:00

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)

YimingWu commented

2023-04-17 13:23:30 +02:00

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

Sybren A. Stüvel commented

2023-04-18 11:30:47 +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?

YimingWu commented

2023-04-18 11:33:48 +02:00

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

Nathan Vegdahl commented

2023-04-18 12:23:04 +02:00

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.

YimingWu commented

2023-04-18 16:31:25 +02:00

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

and removed

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

Nathan Vegdahl commented

2023-04-21 13:03:56 +02:00

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?

Julien DUROURE commented

2023-04-21 13:22:26 +02:00

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

👍 2

Alexander Gavrilov commented

2023-04-24 12:56:15 +02:00

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

Nathan Vegdahl commented

2023-04-24 14:01:37 +02:00

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.

Nathan Vegdahl commented

2023-04-24 14:11:45 +02:00

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.

Nathan Vegdahl commented

2023-04-24 14:30:23 +02:00

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.

🚀 1

Sybren A. Stüvel commented

2023-05-04 09:22:22 +02:00

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

Nathan Vegdahl commented

2023-05-05 11:56:34 +02:00

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

Sybren A. Stüvel commented

2023-05-05 12:20:37 +02:00

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

👍 1

Julien DUROURE commented

2023-08-15 18:59:05 +02:00

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?

YimingWu commented

2023-08-16 03:50:59 +02:00

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.

Nathan Vegdahl commented

2023-08-24 15:06:22 +02:00

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

Nathan Vegdahl referenced a pull request that will close this issue

2023-09-22 10:44:09 +02:00

Fix #107030: return accurate action frame ranges from the Python API #112709

Nathan Vegdahl commented

2023-09-25 18:19:32 +02:00

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.

👍 1

Nathan Vegdahl referenced this issue from a commit

2023-09-26 18:19:06 +02:00

Fix #107030: return accurate action frame ranges from the Python API

Nathan Vegdahl closed this issue

2023-09-26 18:19:07 +02:00

Blender Bot added

and removed