I’m not much at scripting, but hopefully if it’s possible it’s also something simple enough to use in drivers? I’m thinking this would be useful, because if I could get the slope for something like the X location F-curve, it would be the same as the delta for X location. (I think that’s right?)
For rigging various things, knowing the change in rate for a value between frames would be quite useful. (Like a “speedometer” that just works, or having wheels turn the correct amount regardless if a car is doing something like going around a curve.) Also gets around some of the limitations by calculating other things based on transforms.
I’m sure in some specific cases that value would be infinite or NAN (value jumping vertically for curve set to constant), but I’m thinking in most case where the F-curve is typically a curve.
Well, there’s no slope for a single point in time, you’ll need to get the F-Curve coordinates of two different points (e.g. current and next frame, or current and current + 0.01 subframes?!)
That’s close, but keep in mind an F-curve can be an actual curve… Thinking of something more like this…
And getting the values for the actual scripting? Active F-curve Y-location for X (time on curve) seems to be grayed out so I can’t select and copy. I can understand not directly editing it for whatever reason, but it’s a problem wanting to copy that value quickly for use.
Also saw some reference to SymPy or SciPy that seem to be related, those come with the Python included in Blender?
Hmmm… Also thinking about it, perhaps it could be the simple slope you referenced in regards to location of the point compared to its right handle location? Still wonderng what would be the best/easiest way?
More or less looking for a suggested code snippet I could put in a driver.
The state of Blender’s Python “packaging” is a bigger mess than usual for the Python eco system. My understanding is that Blender started out a long time ago as “C codebase enhanced by Python scripting”, and is currently in the transition to “Python codebase enhanced by C extensions”. My suggestion would be to stop bundling Python with blender, and start building against the (by now) excellent available binary distributions like Continuum’s Anaconda. Anyway, there is no technical reason why you can’t use SciPy in Blender, except that even if you manage to get it working, it will be a nightmare for other people to get your script in a workable state
If you just want to get the slope of an fcurve however, you don’t need SciPy at all. First you need to get the fcurve object, then you do this:
def my_slope(frame):
fcurve = bpy.data.actions[0].fcurves[0] # You'll have to replace this line, depending on your use case....
d = 0.01
a = fcurve.evaluate(frame-d)
b = fcurve.evaluate(frame+d)
return (b-a) / 2 / d
bpy.app.driver_namespace["my_slope"] = my_slope
The code may not be completely correct because I am writing it from memory, but the basic idea should work, and I have used this in a driver before.
Numerical integration would also be possible. But that’s a story for another Post…
I beg to differ, that’s precisely what derivatives are for. What you (and Bayesian) are describing is a “finite difference approximation”, where you are treating the curve locally as a line.
You also can analytically compute the derivative of a Bezier curve if you know its order and control points. (I don’t know the API for that, but it should be there)
Yes, BeerBaron, there is an analytical solution for the slope of a Beziercurve. In Blender drivers however, I think that would be the wrong approach. First you need to figure out the control points, which takes more time than evaluating the curve (because you have to do it in Python). It also takes looping through key frames to find the two key frames adjacent to the current frame. Second problem is that F-Curves aren’t always bezier-interpolated. Third problem is that there are new easing in/out modes which would mess even further with analytical solutions.
However, the delta I gave may not be right for all cases. I can imagine situations where d=0.5 or even d=1 would be better. For example when trying to fake motion blur, we actually want the difference of one frame to the other instead of the exact tangent slope, which may be quite different.
