Physics ignores unit scale #61313

New Issue

Thomas Androxman · 2019-02-08T10:04:10+01:00

Thomas Androxman commented

2019-02-08 10:04:10 +01:00

(Model units centimeters. Scale 0.1)

A simgle ball 10cm diameter placed 1m over a simple plane should free-fall down to the plane in exactly 0.45s (Physics calculation) .
At 60fps this should be 27 frames.

In Blender (with simulation speed left to 1) the fall takes 87 frames; as if physics in blender work 3 times slower than in reality.
We could artificially bump the simulation speed to 3, but shouldn't the default be physically accurate to start ?

(Model units centimeters. Scale 0.1) A simgle ball 10cm diameter placed 1m over a simple plane should free-fall down to the plane in exactly 0.45s [(Physics calculation) ](https://www.omnicalculator.com/physics/free-fall). At 60fps this should be 27 frames. In Blender (with simulation speed left to 1) the fall takes 87 frames; as if physics in blender work 3 times slower than in reality. We could artificially bump the simulation speed to 3, but shouldn't the default be physically accurate to start ?

Thomas Androxman commented

2019-02-08 10:04:10 +01:00

Added subscriber: @ThomasAn

blender-admin commented

2019-02-08 10:04:10 +01:00

#52238 was marked as duplicate of this issue

Sergey Sharybin commented

2019-02-08 10:21:56 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2019-02-08 10:21:57 +01:00

Please always attach file which demonstrates the issue.
In my quick experiment rigid body simulation works correct on both 24 and 60 fps. One thing though: changing fps does not invalidate cache, so should be careful there.

Please always attach file which demonstrates the issue. In my quick experiment rigid body simulation works correct on both 24 and 60 fps. One thing though: changing fps does not invalidate cache, so should be careful there.

Thomas Androxman commented

2019-02-08 10:34:47 +01:00

I think I triple checked, but there is always the chance I missed a setting somewhere. I am attaching the file here.

When the simulation is run it takes 87 frames to hit the plane. It should take only 27 frames.BouncingBall.blend

I think I triple checked, but there is always the chance I missed a setting somewhere. I am attaching the file here. When the simulation is run it takes 87 frames to hit the plane. It should take only 27 frames.[BouncingBall.blend](https://archive.blender.org/developer/F6547498/BouncingBall.blend)

Sergey Sharybin commented

2019-02-08 10:51:17 +01:00

Added subscriber: @JacquesLucke

Sergey Sharybin commented

2019-02-08 10:51:17 +01:00

Ok, now i see what's happening.
The physics works in blender units, prior to the unit system is taking place. In fact, the unit system was originally an interface-only thing, and lots of areas are not aware of this.

In your case the ball is falling from height of 10.5m as seen by the physics.

@JacquesLucke , is it something fun for you to dig into? If so, please claim the report :)

Ok, now i see what's happening. The physics works in blender units, prior to the unit system is taking place. In fact, the unit system was originally an interface-only thing, and lots of areas are not aware of this. In your case the ball is falling from height of 10.5m as seen by the physics. @JacquesLucke , is it something fun for you to dig into? If so, please claim the report :)

Sergey Sharybin changed title from ~~Gravity too slow~~ to Physics ignores unit scale

2019-02-08 10:51:56 +01:00

Jacques Lucke self-assigned this 2019-02-08 11:07:17 +01:00

Jacques Lucke commented

2019-02-08 11:07:17 +01:00

Not sure if this will be fun, but yeah, I will dig into it.

Jacques Lucke commented

2019-02-08 12:34:50 +01:00

Ok, it is a bit frustrating. Mainly because one bullet wiki has been moved but not all pages are back. Therefore many links I find on the topic send me to 404 errors.
Most topics just link to https:*pybullet.org/mediawiki-1.5.8/index.php?title=Scaling_The_World. But this page is down and I cannot find any (cached) version of it... (It will take some more time until the information is available again: https:*github.com/bulletphysics/bullet3/issues/2048)

I hoped that there is a setting that controls the unit scale inside of bullet. However I could not find any details on that, although sometimes people mention that the unit scale could be set to a cm or so..
In general Bullet seems to have problems when the objects are very small. Therefore scaling everything down as preprocessing for Bullet might not work well (that would probably be a fairly big task by itself).
Also the Unit Scale exists in Blender so that this is not necessary. Maybe one could get around scaling all meshes down using some scaled container, but those still would have to be moved in the right positions, forces have to be changed, ...

Other solutions people suggested are to increase the gravity constant or to run the simulation faster. Both of which aren't real solutions to the problem.

Unless I can find a simple way to set the unit scale in bullet, this project feels like a time sink and is probably not worth the effort for now.
Interestingly, the issue seems to "fixed" in the bullet bug tracker, but the fix only seems to be to scale everything down beforehand and to use smaller time step.

Ok, it **is** a bit frustrating. Mainly because one bullet wiki has been moved but not all pages are back. Therefore many links I find on the topic send me to 404 errors. Most topics just link to https:*pybullet.org/mediawiki-1.5.8/index.php?title=Scaling_The_World. But this page is down and I cannot find any (cached) version of it... (It will take some more time until the information is available again: https:*github.com/bulletphysics/bullet3/issues/2048) I hoped that there is a setting that controls the unit scale inside of bullet. However I could not find any details on that, although sometimes people mention that the unit scale could be set to a cm or so.. In general Bullet seems to have problems when the objects are very small. Therefore scaling everything down as preprocessing for Bullet might not work well (that would probably be a fairly big task by itself). Also the Unit Scale exists in Blender so that this is not necessary. Maybe one could get around scaling all meshes down using some scaled container, but those still would have to be moved in the right positions, forces have to be changed, ... Other solutions people suggested are to increase the gravity constant or to run the simulation faster. Both of which aren't real solutions to the problem. Unless I can find a simple way to set the unit scale in bullet, this project feels like a time sink and is probably not worth the effort for now. Interestingly, the [issue ](https://code.google.com/archive/p/bullet/issues/45) seems to "fixed" in the bullet bug tracker, but the fix only seems to be to scale everything down beforehand and to use smaller time step.

Brecht Van Lommel commented

2019-02-08 14:25:37 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-02-08 14:25:37 +01:00

Bullet may be an issue, but isn't this just about gravity which is already user configurable in the scene?

It appears that BKE_scene_unit_scale does not affect velocity and acceleration properties (or vectors in general). So the gravity displayed in the UI is wrong, and that could be fixed at least.

The other problem is more of a design issue, maybe out of the scope of the bug tracker. Currently the unit system only affects display and editing of values, which I think is generally a good thing. But it does mean that if you change the unit scale, gravity will change to a different value. We may want to make an exception for some physics constants.

Bullet may be an issue, but isn't this just about gravity which is already user configurable in the scene? It appears that `BKE_scene_unit_scale` does not affect velocity and acceleration properties (or vectors in general). So the gravity displayed in the UI is wrong, and that could be fixed at least. The other problem is more of a design issue, maybe out of the scope of the bug tracker. Currently the unit system only affects display and editing of values, which I think is generally a good thing. But it does mean that if you change the unit scale, gravity will change to a different value. We may want to make an exception for some physics constants.

Jacques Lucke commented

2019-08-21 15:35:43 +02:00

Added subscribers: @bcmpinc, @LazyDodo, @dark999, @Stewie, @SteffenD

Adam Stankiewicz commented

2019-09-02 03:01:31 +02:00

Added subscriber: @sheerun

Adam Stankiewicz commented

2019-09-02 03:01:31 +02:00

I wanted to create "proxy" prop for that but currently python API cannot create "array" properties. It would be helpful if you added this option... (e.g. array=3). Here's relevant C code:

prop = RNA_def_property(srna, "gravity", PROP_FLOAT, PROP_ACCELERATION);
RNA_def_property_float_sdna(prop, NULL, "physics_settings.gravity");
RNA_def_property_array(prop, 3); // -> you cannot do it in python

I wanted to create "proxy" prop for that but currently python API cannot create "array" properties. It would be helpful if you added this option... (e.g. array=3). Here's relevant C code: ``` prop = RNA_def_property(srna, "gravity", PROP_FLOAT, PROP_ACCELERATION); RNA_def_property_float_sdna(prop, NULL, "physics_settings.gravity"); RNA_def_property_array(prop, 3); // -> you cannot do it in python

Jacques Lucke commented

2019-09-02 08:47:33 +02:00

You have to use a FloatVectorProperty in Python.

You have to use a `FloatVectorProperty` in Python.

blender-admin commented

2019-09-17 13:37:43 +02:00

This issue was referenced by c25f5a375e

This issue was referenced by c25f5a375e6c7469ee55a300a92eac362a46f697

Brecht Van Lommel commented

2019-09-17 13:44:13 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-09-17 13:44:13 +02:00

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

Physics ignores unit scale #61313