Different frames make rigid bodies act differently

Question

So I am writing a small script to set initial speeds for objects in the Rigid Body system. It is really bare bones right now, but it essentially sets a keyframe for the selected object on the frame number of a variable called start_frame.

The goal of the script is so I can choose a start frame and a speed, and the object will have all of the correct keyframes set so it can just launch off with an initial speed. The problem is that depending on what frame I set start_frame to be, the cube reacts differently.

Here is what I mean:

If start_frame equals 1, the object is launched and then falls off the plane.

If start_frame equals any number greater than 1, the object doesn't travel as far.

From what I understand, there shouldn't be any difference because the distance between the start and end keyframes is always the same.

I looked at the graph editor but the only change I am seeing between the two conditions is being shifted, just like it should be.

I am so confused why changing the frame from 1 to anything above 1 would give such a different result.

So is there anything special about frame 1? And if so, how can I avoid this problem in my script?

Answer 1

The problem is the animation starts at frame_start and ends at frame_end and since end_frame = start_frame + speed the duration is always the same but shifted.
To achieve the desired effect the animation duration should get longer when frame_start gets larger, one way to do it is to set the first keyframe at 0.
so the first key frame shouldn't be the start_frame :

    # First keyframe
    scene.frame_current = 0
    bpy.ops.anim.keyframe_insert(type='Location')
    print(start_location)

---

if you want to start at frame_start and end at frame_end and get different results you have to change the frame_end expression :

frame_end = speed + 2*frame_start

this way the delay the start the longer the duration is , giving the cube lower speed ( less momentum ) and it will travel shorter

Answer 2

So in order to fix this problem, the steps per second need to be a multiple of the current frames per second. Not exactly sure why this is, but it will make everything more stable!