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

[Roger Wickes]

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