A Rigid Body does not keep the initial velocity after the animated checkbox is disabled #47402

New Issue

Fabrizio · 2016-02-13T03:21:01+01:00

Fabrizio commented

2016-02-13 03:21:01 +01:00

Blender Version
Broken: 2.83

Short description of error
Rigid Body objects whose "animated" option is unchecked (for example by a keyframe) do not maintain the velocity that was in the previous frame.
It is interesting to note that by setting small values for the rigid body parameters (in the Scene tab) "speed" and "steps per second" the initial speed is maintained.
For exemple:

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
In the attached file there are six objects whose animation is disabled during the simulation.

Open the attached file
Run the animation

Note the velocity changing when the checkbox is disabled.

Analyzing the bullet code we can see that the speed (btRigidBody::m_linearVelocity) changes in RB_dworld_step_simulation, more specifically calculateVelocity.

test2.blend

**Blender Version** Broken: 2.83 **Short description of error** Rigid Body objects whose "animated" option is unchecked (for example by a keyframe) do not maintain the velocity that was in the previous frame. It is interesting to note that by setting small values for the rigid body parameters (in the `Scene` tab) "speed" and "steps per second" the initial speed is maintained. For exemple: - 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** In the attached file there are six objects whose animation is disabled during the simulation. - Open the attached file - Run the animation Note the velocity changing when the checkbox is disabled. Analyzing the bullet code we can see that the speed (`btRigidBody::m_linearVelocity`) changes in `RB_dworld_step_simulation`, more specifically `calculateVelocity`. [test2.blend](https://archive.blender.org/developer/F282447/test2.blend)

blender-admin commented

2016-02-13 03:21:01 +01:00

#69396 was marked as duplicate of this issue

blender-admin commented

2016-02-13 03:21:01 +01:00

#61693 was marked as duplicate of this issue

Fabrizio commented

2016-02-13 03:21:02 +01:00

Changed status to: 'Open'

Fabrizio commented

2016-02-13 03:21:02 +01:00

Added subscriber: @FabrizioP

Bastien Montagne commented

2016-02-13 10:33:19 +01:00

Added subscribers: @sreich, @mont29

Sergej Reich was assigned by Bastien Montagne

2016-02-13 10:33:19 +01:00

Bastien Montagne commented

2016-02-13 10:33:19 +01:00

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

Fabrizio commented

2016-02-13 11:26:08 +01:00

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

lower case commented

2016-02-13 13:14:34 +01:00

Added subscriber: @lowercase

lower case commented

2016-02-13 13:14:34 +01:00

I think this was the expected workflow, check this post

I think this was the expected workflow, check this [post ](http://blenderartists.org/forum/showthread.php?255667-GSoC-2012-Bullet-Integration&p=2183261&viewfull=1#post2183261)

Fabrizio commented

2016-02-14 22:18:36 +01:00

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 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.

lower case commented

2016-02-15 05:07:56 +01:00

seems to be the same bug as here: https://developer.blender.org/T39529

Fabrizio commented

2016-02-15 16:43:08 +01:00

I saw the report #39529 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.

I saw the report #39529 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.

Sergej Reich commented

2016-02-15 17:16:08 +01:00

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 #39529.

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 #39529.

Sergej Reich was unassigned by Dalai Felinto

2019-12-23 16:37:18 +01:00

Germano Cavalcante commented

2020-01-23 04:26:25 +01:00

Added subscriber: @mano-wii