action.frame_range
span always >=1 when there's only 1 key frame in it.
#107030
Labels
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#107030
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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)
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?
cc @angavrilov in commit
5d59b38605
frame_range wrong value when only 1 keyframeto `action.frame_range` span always >=1 when there's only 1 key frame in it.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?
@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.Adding to what YimingWu (@ChengduLittleA) said, I did a few tests to check various cases:
(3.0, 4.0)
.(3.0, 3.5)
.(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.
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
andBKE_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: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
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].
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.
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:
So we'll want to change that as well.
@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?
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).
This change was tag as 4.0 because of breaking change.
Is it still planned?
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.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.
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 clipstart
/end
, and the strip's clipscale
andrepeat
. 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 byaction.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.