Page MenuHome

A Rigid Body does not keep the initial velocity after the animated checkbox is disabled
Open, NormalPublic


System Information
Window 7 home premium SP1

System Information
Window 7 home premium SP1

Blender Version
Broken: 2.76b f337fea
Worked: (optional)

Short description of error
A Rigid Body (RB) with the following fcurves:

  • animated checkbox enabled from frame 0 to frame F-1 and from frame F with the animated checkbox disabled,
  • locationX keyframed in order to give a velocity to the RB (eg. constant slope from frame 0 to frame 250)

does not keep its initial velocity after the frame F.
The velocity assumed by the RB depends on if the F is even or odd, the speed and the steps per second of the simulation.

When the the rigid body parameters (in the scene tab) "speed" and "steps per second" are 1.0 and 60.0 (default):
if the frame F is even the RB is faster, if the frame F is odd the RB is slower then the initial velocity.

With "speed" 2.0, 4.0 the RB seems to keep the initial velocity.
With "speed" 3.0, 5.0 the differences appear again.

Increasing the "steps per second" reduces the differece, but it is still appreciable.

Exact steps for others to reproduce the error
6 Rigid Bodies (Cubes) with dynamic and animated checkbox enabled from frame 0 and from frame F the checkbox animated is disabled. The "LocationX" is also keyframed in order to have a velocity when the animated checkbox is disabled.

To semplify and make more evident the effects, the f-curve is at constant slope (type of handle vector; keyframe=0 X=0, keyframe=250 X=25). Furthermore, the gravity is disabled and the "translation damping" is set to 0.0.

To check the velocity there is another Rigid Body that can be taken as reference, with the same f-curve for locationX, but with the animated checkbox kept enabled.

The details are in the following script

import bpy
# delete the the cube in the start-up file
# add 7 cubes along the y axis
for Y in [-9,-6,-3,0,3,6,9]:
    bpy.ops.mesh.primitive_cube_add(radius=1.0, location=(0,Y,0))
# define a material'Ocra')
# add to each cube a fcurve of constant slope 0.1 units per frame 
# from frame 0 to frame 250
bpy.context.scene.frame_start = 0
bpy.context.scene.frame_current = 0
for obj in
    if obj.type=="MESH":
        # add a fcurve of constant slope (0.1 units per frame) 
        # from frame 0 to frame 250 to each cube 
        obj.location[0] = 0.0
        obj.keyframe_insert(data_path="location", frame=0.0, index=0)
        obj.location[0] = 25.0
        obj.keyframe_insert(data_path="location", frame=250.0, index=0)
        obj.keyframe_insert(data_path="rigid_body.kinematic", frame=0.0, index=-1)
        if Y!=0:
            if Y>0:
            obj.keyframe_insert(data_path="rigid_body.kinematic", frame=F, index=-1)
            bpy.ops.font.text_insert(text="Animation checkbox disabled at frame "+str(F))
            bpy.ops.font.text_insert(text="Reference - animation checkbox always enabled")
bpy.context.scene.use_gravity = False

Please see also the attached .blend file



Event Timeline

Fabrizio (FabrizioP) raised the priority of this task from to Needs Triage by Developer.
Fabrizio (FabrizioP) updated the task description. (Show Details)
Fabrizio (FabrizioP) set Type to Bug.

I’m pretty sure that things like this 'Animated' checkbox (but also others, like 'Dynamic', etc.) should absolutely not be animatable? @Sergej Reich (sergof), what do you say?

Bastien Montagne (mont29) lowered the priority of this task from Needs Triage by Developer to Normal.Feb 13 2016, 10:33 AM

I hope that the result of my report does not be the removal of the feature.

I think this was the expected workflow, check this post

I checked the workflow I have used against the expected workflow indicated in the post and in the linked video (10'36" from the begining).

The expected workflow requires an additional keyframe with the "animated checkbox" enabled a frame before the one in which is disabled.

I added these keyframes, but the result does not change.

I saw the report T39529 before sending mine.

It seems that it is a different bug related to the starting frame of the Rigid Body cache. If it is the frame in which the animation is disabled the RB stops its path in that point. To avoid this problem I started the simulation at first frame (defult value).

In the case I reported, the RB does not stop, but it continues with a velocity different from the initial velocity that depends from the frame (odd/even) at which the animation has been disabled.

There shouldn't be any problems with animating these properties in principle.

The general issue is that we have a render frame rate at which animations are updated and a number of simulation steps, depending on how you choose these two you'll get different results.
This is a fundamental issue for simulations in blender. Currently the animation system is only evaluated at the render frame rate, but we need to evaluate it at the simulation rate.
One workaround that should work is to use a multiple of the render frame rate for the number of simulation steps.
The speed setting has an effect, because it adjusts the number of steps internally.

Fabrizio is right, it doesn't seem to be related to T39529.