[Bf-committers] Question (possible issue) about how F-Curve Cycles are calculated

[Mathew Burrack]

In researching an issue with the F-Curve Cycles, I discovered something that I don't think is quite right.

Right now, the cycle system is treating the time as floats, yet technically they're not: they're discreet integer frames. This results in calculations that would make sense for a non-integer time, but not for discreet frames.

For example, say you want a 24-frame, 1 second movie of a box moving left to right. So, since frames count starting at 0, you set keyframes at frame 0 and frame 23. Then you want it to loop for 10 seconds, so that the second 24 frames are identical to the first 24, etc. So you add a Cycle modifier with Cycles=9 (9 additional cycles on top of the initial one).

The Graph of the cycle in the Graph Editor looks all pretty and correct, yet it's not, and it actually does a good job of showing what's actually wrong. At frame 23, the box is in the right position (defined by the keyframe). At frame 24, the box SHOULD be at starting position, i.e. identical to frame 0. However, it's actually at the same position as frame 1, because the first cycle's animation curve got calculated starting at time 23.0, not 24.0. 

The end position of the cycle similarly has issues. If you go to frame 45, the box should be in the same position as frame 23 (end frame of cycle #1). However, it's actually at the same position as frame 22, because the end of the curve is calculated from time 46.0, even though at that point it's really the start of cycle #2, not the end of cycle #1. In other words, the Cycle code assumes cycles are contiguous in floating-point space (time 0-23.0, time 23.0-46.0, etc), instead of integer space (time 0-23, time 24-45, time 46-71, etc).

I submitted a bug about a separate issue (last Cycle not getting the end time calculated right, bug #24092) but it actually has a .blend file attached that illustrates this issue pretty well, too.

Now, to me, this doesn't make sense; the frames are discreet frames. However, since I'm new to Blender, I don't know if it was conscious decision for animation time to be deliberately floating-point-time instead of frame-based, so I figured the best option was to get some input from Blender experts before declaring it a "bug".

Thoughts, anyone?

Thanks!
-Mathew