[Bf-committers] Question (possible issue) about how F-Curve Cycles are calculated
Roger Wickes
rogerwickes at yahoo.com
Sat Oct 2 21:08:56 CEST 2010
frames for rendering start at 1, not 0. so you should go 1-24, with 25=1.
--Roger
Check out my website at www.rogerwickes.com for a good deal on my book and
training course, as well as information about my latest activities. Use coupon
Papasmurf for $15 off!
----- Original Message ----
From: Mathew Burrack <mburrack at yahoo.com>
To: bf-committers at blender.org
Sent: Fri, October 1, 2010 3:05:23 PM
Subject: [Bf-committers] Question (possible issue) about how F-Curve Cycles are
calculated
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
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
More information about the Bf-committers
mailing list