[Bf-committers] Problems with time in do_nla()
rolandh at reed-witting.com
Wed Jan 4 20:38:13 CET 2006
In trying to get Action Baking working properly (nice, optimized
keying), I've run across some interesting traits of Blender's time
system, and the NLA stride bone option, in particular.
First, I'm not sure why I never realized it, but Blender's global
current frame variable is a short integer. Why it is not a float, I
do not understand. It seems that a lot of the worries about
fractional frames for things like motion blur, etc., would go away if
someone took on the daunting task of converting it to a float
variable. Of course, there's probably a very good reason that I'm
missing, but at the moment, I don't get it.
A problem that I've run across, and I invite anyone familiar with the
NLA Stride Bone code to comment, is that when using a StrideBone on a
path, the full range of the action is never used. Upon using a
modified compile of Blender, I had it give me the Action frame number
that is was using at each stage during NLA, and, depending on the
length of the Action, the length of the Stride, etc., the StrideBone
feature would start the Action at various places: frame 3.37, frame
7.856, etc., but not frame 1, where it ought to start.
I've been tracing the code by hand, trying to figure out exactly
where things begin to get screwy, and I've run it down to the
calculation of the ctime value, before it gets converted into
striptime. Frame 1 of a strip with StrideBone should return frame 1
of the associated Action; likewise, strip frames that are a multiple
of the number of repeats of the cycle (+1, of course) should return 1
for their action frame. But they don't.
Comments or clarifications?
Roland Hess - harkyman
More information about the Bf-committers