Blender physics. Gravity test. Solid body. Some considerations. #36974

New Issue

william willybid · 2013-10-06T17:44:32+02:00

william willybid commented

2013-10-06 17:44:32 +02:00

%%%--- Blender version 2.68.0 r5836

As you can see the attached blend file and video file too, I tested gravity and solid body physics. The scene is very simple. I built a sphere and two cubes. I placed the sphere with the origin at exactly 9.81 meters from down cube surface, and configured the physics of each 3 bodies just to have the ball bouncing between the two cubes. I expected that the sphere starts falling for gravity at certain speed with default gravity acceleration (9.81) while falling. And I expected a deceleration after bouncing with a general deceleration value and the consequent general diminution of bounces height.
So I definitely expected the sphere slows down progressively till totally stop.
But the sphere accelerate progressively.
Also at a certain point of the video the sphere passes trough the cube placed at the down side...

In a real world situations it doesn't behave so.

If colliding bodies are perfectly elastic (bouncine = 1) and there is not any actrict due to a fluid presence (air for example), I expected to see the sphere bouncing for ever TILL THE SAME height and speed because going down the sphere accelerate and going up it obviously decelerate.
In other words if bouncine < 1, sphere bounces must falloff till completely stop.
So my supposition is that the ball behaves as if bouncine > 1... But I setted it with a value of 0.8, as you can see in attached files...

Am I wrong interpreting blender physics values? If I'm right there is some bug in blender?

If my physics knowledge and evaluations are correct, the following is my supposed bug list considered in attached files:

1st bug) A solid body cannot pass trough another. In the video it happens. How it is possible? How can I prevent it?
2nd bug) Blender bouncine value is too strong because a body seems to be perfectly elastic with values of bouncine < 1; It implies some confusion on which value to use for that option.
3rd bug) The ball is placed at 9.81 meters from the down cube. So I expected to see the ball hitting the cube after 1 second. But id doesn't happen. The collision happens after about 1.5. It seems there is an incorrect timing... To have the collision at the correct timing I have to set the frame rate at about 33 frames per sec. (but I don't know video standards matching this value).

Some more precisations for the 3rd point. I suppose blender gravity acceleration (as well as every calculated physic out there) must be FRAME RATE INDEPENDENT.
So if I set the frame rate at 10 frames per sec, the ball from a height of 9.81 meters must accomplish its path and hit the cube in 10 frames from start but animation of course will be a bit jerky accordingly.
If I set the frame rate at 100 frames per sec. the ball must hit the cube in 100 frames (the animation will appear absolutely fluid accordingly with this frame rate).
But IN BOTH CASES the ball MUST hit the cube in the correct time of 1 sec. so the time MUST BE THE SAME, in fact it is the position of the body at each frame that has to be recalculated accordingly on the basis of the chosen frame rate, as happens in real world with real cameras.

In my humble opinion, without these fixes, choosing values for correct simulations in Blender, appear to be a bit confusing because they are not coherent with real world.

I'm not English so I'm sorry for any mistakes, but hope everything is clear. Otherwise ask me more explanations. I'll respond as soon as possible.

Thanks%%%

%%%--- Blender version 2.68.0 r5836 As you can see the attached blend file and video file too, I tested gravity and solid body physics. The scene is very simple. I built a sphere and two cubes. I placed the sphere with the origin at exactly 9.81 meters from down cube surface, and configured the physics of each 3 bodies just to have the ball bouncing between the two cubes. I expected that the sphere starts falling for gravity at certain speed with default gravity acceleration (9.81) while falling. And I expected a deceleration after bouncing with a general deceleration value and the consequent general diminution of bounces height. So I definitely expected the sphere slows down progressively till totally stop. But the sphere accelerate progressively. Also at a certain point of the video the sphere passes trough the cube placed at the down side... In a real world situations it doesn't behave so. If colliding bodies are perfectly elastic (bouncine = 1) and there is not any actrict due to a fluid presence (air for example), I expected to see the sphere bouncing for ever TILL THE SAME height and speed because going down the sphere accelerate and going up it obviously decelerate. In other words if bouncine < 1, sphere bounces must falloff till completely stop. So my supposition is that the ball behaves as if bouncine > 1... But I setted it with a value of 0.8, as you can see in attached files... Am I wrong interpreting blender physics values? If I'm right there is some bug in blender? If my physics knowledge and evaluations are correct, the following is my supposed bug list considered in attached files: 1st bug) A solid body cannot pass trough another. In the video it happens. How it is possible? How can I prevent it? 2nd bug) Blender bouncine value is too strong because a body seems to be perfectly elastic with values of bouncine < 1; It implies some confusion on which value to use for that option. 3rd bug) The ball is placed at 9.81 meters from the down cube. So I expected to see the ball hitting the cube after 1 second. But id doesn't happen. The collision happens after about 1.5. It seems there is an incorrect timing... To have the collision at the correct timing I have to set the frame rate at about 33 frames per sec. (but I don't know video standards matching this value). Some more precisations for the 3rd point. I suppose blender gravity acceleration (as well as every calculated physic out there) must be FRAME RATE INDEPENDENT. So if I set the frame rate at 10 frames per sec, the ball from a height of 9.81 meters must accomplish its path and hit the cube in 10 frames from start but animation of course will be a bit jerky accordingly. If I set the frame rate at 100 frames per sec. the ball must hit the cube in 100 frames (the animation will appear absolutely fluid accordingly with this frame rate). But IN BOTH CASES the ball MUST hit the cube in the correct time of 1 sec. so the time MUST BE THE SAME, in fact it is the position of the body at each frame that has to be recalculated accordingly on the basis of the chosen frame rate, as happens in real world with real cameras. In my humble opinion, without these fixes, choosing values for correct simulations in Blender, appear to be a bit confusing because they are not coherent with real world. I'm not English so I'm sorry for any mistakes, but hope everything is clear. Otherwise ask me more explanations. I'll respond as soon as possible. Thanks%%%

william willybid commented

2013-10-06 17:44:32 +02:00

Changed status to: 'Open'

Brecht Van Lommel commented

2013-10-07 16:28:48 +02:00

%%%1) Physics and collision systems are not perfect, if you make an object move at very high speed it can break through another one. With more steps per second or solver iterations you can get more accurate results. The way this scene is set up the ball will keep going faster and faster so it will always fail at some point, quite standard for rigid body physics simulation as far as I know? Although maybe Bullet is supposed to be able to detect this, I'm not sure.

Bounciness: I'm not sure which physical unit this corresponds to, but indeed seems a bit strange that value 1 would bounce back the object faster. I'm also not sure what "perfectly elastic" means.
I already addressed that in the other bug you reported, an object placed at height 9.81 is not supposed to hit the ground in 1 second:
https://projects.blender.org/tracker/?func=detail&atid=498&aid=36774&group_id=9
Changing the frame rate will adjust the simulation correctly in the 3D view, however it will not modify the scene strip in the sequencer, you will have to update or re-add the scene strip manually. That's not considered a bug, it's a bit confusing but changing scene strips automatically has the potential to break sequencer setups in a way that can't be fixed.

Assigned to Sergej. Could you clarify if 1) and 2) are bugs and fix them if needed?%%%

%%%1) Physics and collision systems are not perfect, if you make an object move at very high speed it can break through another one. With more steps per second or solver iterations you can get more accurate results. The way this scene is set up the ball will keep going faster and faster so it will always fail at some point, quite standard for rigid body physics simulation as far as I know? Although maybe Bullet is supposed to be able to detect this, I'm not sure. 2) Bounciness: I'm not sure which physical unit this corresponds to, but indeed seems a bit strange that value 1 would bounce back the object faster. I'm also not sure what "perfectly elastic" means. 3) I already addressed that in the other bug you reported, an object placed at height 9.81 is not supposed to hit the ground in 1 second: https://projects.blender.org/tracker/?func=detail&atid=498&aid=36774&group_id=9 4) Changing the frame rate will adjust the simulation correctly in the 3D view, however it will not modify the scene strip in the sequencer, you will have to update or re-add the scene strip manually. That's not considered a bug, it's a bit confusing but changing scene strips automatically has the potential to break sequencer setups in a way that can't be fixed. Assigned to Sergej. Could you clarify if 1) and 2) are bugs and fix them if needed?%%%

Sergej Reich commented

2013-10-08 05:09:36 +02:00

%%%1) This is a common problem, see here for how to avoid it: http://wiki.blender.org/index.php/User:Sergof/GSoC2012/Documentation#Simulation_Stability

Bounciness is the restitution of the body. Yes, the current behaviour is not completely correct. I wouldn't call it a bug, these kind of inaccuracies are common for the integration methods used in real time physics.
The behaviour also depends on the number of steps per second and constraint solver iterations made and whether split impulse is enabled.%%%

%%%1) This is a common problem, see here for how to avoid it: http://wiki.blender.org/index.php/User:Sergof/GSoC2012/Documentation#Simulation_Stability 2) Bounciness is the restitution of the body. Yes, the current behaviour is not completely correct. I wouldn't call it a bug, these kind of inaccuracies are common for the integration methods used in real time physics. The behaviour also depends on the number of steps per second and constraint solver iterations made and whether split impulse is enabled.%%%

Sergej Reich commented

2013-10-08 05:36:54 +02:00

%%%1) One more note here, bulelt does have a way of doing continuous collision detection for convex shapes that would avoid the problem in many cases, we need to fix a few bugs before we can use it though.

Closing for now, since these don't seem to be bugs.%%%

%%%1) One more note here, bulelt does have a way of doing continuous collision detection for convex shapes that would avoid the problem in many cases, we need to fix a few bugs before we can use it though. Closing for now, since these don't seem to be bugs.%%%

Sergej Reich commented

2013-10-08 05:36:54 +02:00

Changed status from 'Open' to: 'Archived'

Sergej Reich closed this issue

2013-10-08 05:36:54 +02:00

william willybid commented

2013-10-08 18:09:10 +02:00

%%%Ops I'm sorry I was wrong and a bit confused: the correct formula to calculate the distance traveled is

d = ( a * t ^ 2 ) / 2
d = ( 9.81 * 1 ^ 2 ) / 2 = 4.905

Previously I forgot the " / 2" part of the formula... I'm very sorry...%%%

%%%Ops I'm sorry I was wrong and a bit confused: the correct formula to calculate the distance traveled is d = ( a * t ^ 2 ) / 2 d = ( 9.81 * 1 ^ 2 ) / 2 = 4.905 Previously I forgot the " / 2" part of the formula... I'm very sorry...%%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender physics. Gravity test. Solid body. Some considerations. #36974