How to calculate speed/detect movement per frame?

Question

I've been looking for a way to calculate the speed of an object or bone. On this same site a couple of people have made this same question but any of the scripts I've tried in the current version of Blender don't seem to work (anymore).

What I'd like to have is a driver/drivers that says/say how much an object or bone has moved every frame, so a comparison of the location of the distance of the previous frame to the current frame. This can be a single value or in separate X, Y and Z values, either would work.

Among the scripts I've tried this one seems like a good solution but sadly it mostly returns zeroes for me:

The numbers it pops out seem right but it doesn't seem to be updating at the right rate. I've added this file to the post.

Edit: After tetii's suggestion I did some more experimenting and did get the script to work, somewhat:

The file for this I've provided also, it's the second one. What I've done is simply copy over the driver to the Z-location of the cube. Now the driver for 'dx' is updating correctly, I just don't understand why. So it looks like the script from the linked post by Rich Sedman can work, there just seems to be some issue with the way it uses variables or I misunderstood something.

import bpy

attributes = {}

def drv_calc_change(frame, attr, value):
# Used to calculate the change of a property (eg, x-coord) between one frame and the next.

    # Determine whether we already have a value for this attribute
    if attr in attributes:
        attribute = attributes[attr]
    else:
        # Not found - create a new record for it and store it
        attribute = {'frame':frame, 'value':value}
        attributes[attr] = attribute

    # Calculate the difference
    difference = value - attribute['value']

    # If new frame then store the new value to use next time.
    if frame != attribute['frame']:
        attribute['frame'] = frame
        attribute['value'] = value
        attributes[attr] = attribute

    return difference

if 'drv_calc_change' in bpy.app.driver_namespace:
    del bpy.app.driver_namespace['drv_calc_change']
bpy.app.driver_namespace['drv_calc_change'] = drv_calc_change

First file: Second file:

Answer 1

Here's a scriptless solution that doesn't require working with an alpha build, which is nonetheless dynamic, provided you are interested in the velocity only during a single action. Starting with the file provided:

1. Duplicate Cube to Cube.002. Move this duplicate to a new collection.
2. Open the NLA. Push down the Cube.002 action to a new NLA track. Set this action to reference the same action as Cube (CubeAction).
3. Change the driver for Cube.001 to measure the distance between Cube and Cube.002.
4. Move Cube.002's NLA strip one unit in the X (time) axis.
5. Optionally, disable your new collection in viewports and renders.

Our duplicate uses the same action as our original, but lags by 1 frame, allowing us to measure exactly how much distance is traversed in a single frame. Because the strips reference the exact same action data, we can continue to edit this action, and our velocities will update with our edits.

If already using the NLA to combine multiple actions, or if interested in the velocity through multiple actions (perhaps for exporting a file containing multiple actions), this is not a good solution.

There will also be complications based on dependencies. They can be worked around, by duplicating parents/targets (and their parents/targets, and so on) and shifting NLA action strips in the same way, but that will rapidly become unworkable. However, the technique will work perfectly fine for, say, an armature with a baked animation.

Answer 2

About the 1st .blend file

I think the problem is that the Cube object itself is the target of its own variables. The result of dumping the values of the variable from the function, drv_calc_change, is shown below. This gave the wrong result that var had values in other frames.

On the other hand, the API document has the following description.

use_self

Include a ‘self’ variable in the name-space, so drivers can easily reference the data being modified (object, bone, etc…)

I don't think this wording directly says the solution, but it seems to work fine when I try it.

I hope someone can provide a technical explanation.

Edit: Added an animated image
Notice how the smaller cube now moves smoothly? I printed the difference value to the console, but I seems it doesn't feel practical.

Answer 3

Have you tried translating your script into Simulation nodes? (Blender 3.5 build).You can do the same frame by frame calculations and attribute storage and then translate that into a set of drivers.

@celestialmaze on twitter has done some experimentations in this vain. Dissecting this thread should shed some light on his approach: https://twitter.com/cmzw_/status/1598349619058003970 (scroll for the node graph).

Answer 4

I tried to tackle this problem with Animation Nodes, I read in a different thread that it could be a potential solution. I've only started using them today but this is what I put together: (I hope everything is clear enough, I squashed everything together to be able to make a .gif out of a it.)

What this does is subtract the cube's location data of the previous frame (Frame - 1.00) from the current frame, per axis. Then it feeds the results into the location data of another object, a sphere. I tried to feed the results into custom properties at first but when trying to use their value in other drivers they wouldn't update.