Regression: Physics force field strength affect varies inversely proportion to physics substeps per frame #98272

New Issue

Peter Goodman · 2022-05-19T23:20:26+02:00

Peter Goodman commented

2022-05-19 23:20:26 +02:00

System Information
Operating system: Windows 10 Enterprise
Graphics card: Nvidia Quadro RTX 4000

Blender Version
Broken: 3.1.0 (same in 3.3.0 alpha)
Worked: 2.83.20

Caused by 1aa54d4921

Short description of error
Physics force field affect is inversely proportional to the rigid body world solver substeps per frame. For example if you increase steps per frame by x10, the force effect is x1/10. Thus to maintain the same force result you have to match any changes to the substeps per frame to changes to the factor on force strength.
This issue doesn't exist with 2.83.20 and I noticed that this older version had 'steps per second' which has since changed to 'substeps per frame', so I suspect there might be some issue related to this change.

Exact steps for others to reproduce the error
See attached '2022-05-19 force substep dependence.blend'. 2022-05-19 force substep dependence.blend
Alternatively the issue is easy to recreate...

Start new file
Translate cube in +x direction by 4 units
Add active rigid body to cube
Set gravity strength to zero in rigid body world settings
Add force field at origin, and set strength to 1000
Set timeline end to 30
Play animation and note how far the cube moves by the end frame
Increase the substeps per frame by x100 from default 10 to 1000
Rerun animation and note that cube accelerates much more slowly
Increase force field strength by x100
Rerun animation and note that cube now moves same as in #7

**System Information** Operating system: Windows 10 Enterprise Graphics card: Nvidia Quadro RTX 4000 **Blender Version** Broken: 3.1.0 (same in 3.3.0 alpha) Worked: 2.83.20 Caused by 1aa54d4921 **Short description of error** Physics force field affect is inversely proportional to the rigid body world solver substeps per frame. For example if you increase steps per frame by x10, the force effect is x1/10. Thus to maintain the same force result you have to match any changes to the substeps per frame to changes to the factor on force strength. This issue doesn't exist with 2.83.20 and I noticed that this older version had 'steps per second' which has since changed to 'substeps per frame', so I suspect there might be some issue related to this change. **Exact steps for others to reproduce the error** See attached '2022-05-19 force substep dependence.blend'. [2022-05-19 force substep dependence.blend](https://archive.blender.org/developer/F13091758/2022-05-19_force_substep_dependence.blend) Alternatively the issue is easy to recreate... 1) Start new file 2) Translate cube in +x direction by 4 units 3) Add active rigid body to cube 4) Set gravity strength to zero in rigid body world settings 5) Add force field at origin, and set strength to 1000 6) Set timeline end to 30 7) Play animation and note how far the cube moves by the end frame 8) Increase the substeps per frame by x100 from default 10 to 1000 9) Rerun animation and note that cube accelerates much more slowly 10) Increase force field strength by x100 11) Rerun animation and note that cube now moves same as in #7

Peter Goodman commented

2022-05-19 23:20:26 +02:00

Added subscriber: @badbunny_uk

Philipp Oeser commented

2022-05-20 10:03:44 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-05-20 10:03:44 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-05-20 10:03:44 +02:00

Can confirm, will check

Philipp Oeser commented

2022-05-20 10:59:27 +02:00

Added subscribers: @JacquesLucke, @ZedDB, @brecht

Philipp Oeser commented

2022-05-20 10:59:27 +02:00

Caused by 1aa54d4921
I will dare setting this to High prio since we know what caused this and it basically makes using substeps in combination with forcefields useless.
(but prio could be lowered again since rigidbodies lack a dev atm)

CC @ZedDB
CC @JacquesLucke
CC @brecht

Caused by 1aa54d4921 I will dare setting this to High prio since we know what caused this and it basically makes using substeps in combination with forcefields useless. (but prio could be lowered again since rigidbodies lack a dev atm) CC @ZedDB CC @JacquesLucke CC @brecht

Philipp Oeser changed title from ~~Physics force field strength affect varies inversely proportion to physics substeps per frame~~ to Regression: Physics force field strength affect varies inversely proportion to physics substeps per frame

2022-05-20 10:59:41 +02:00

Jacques Lucke commented

2022-05-20 13:07:24 +02:00

It seems like the issue is that the beginning of btDiscreteDynamicsWorld::stepSimulation computes that there should only be one subset. clampedSimulationSteps always ends up being 1 for me. I don't really know why that is yet. The meaning of the timeStep and fixedTimeStep input to the function is not clear to me.

This might have been broken by the change to the parameters that are passed to RB_dworld_step_simulation.

It seems like the issue is that the beginning of `btDiscreteDynamicsWorld::stepSimulation` computes that there should only be one subset. `clampedSimulationSteps` always ends up being 1 for me. I don't really know why that is yet. The meaning of the `timeStep` and `fixedTimeStep` input to the function is not clear to me. This might have been broken by the change to the parameters that are passed to `RB_dworld_step_simulation`.

Philipp Oeser commented

2022-05-20 13:30:25 +02:00

Added subscriber: @sreich

Philipp Oeser commented

2022-05-20 13:30:25 +02:00

CC @sreich

Lukas Tönne commented

2022-06-11 11:41:36 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2022-06-11 11:41:36 +02:00

The problem here is that the force value of the RigidBody is temporary and gets reset to zero after each Bullet simulation step. The first (Blender) substep has the correct value set by rigidbody_update_simulation (called outside the substep loop), but after that the external force on the body is zero and no further impulse is added.

The smaller substep number makes a larger timestep which increases the impulse added in the first timestep. In the remaining substeps the body just coasts at a constant velocity and no further impulse is added. If the force was set correctly in each substep we could expect the smaller per-step impulse to be compensated by the larger step number and the overall impulse over the whole timestep to be the same.

So the solution should be to call rigidbody_update_simulation for each of the substeps to ensure correct force values.

The arguments to the Bullet step function are actually correct (stackoverflow explanation ):

timeStep: Overall actual time step in seconds. Physical time since stepSimulation was last called.
fixedTimeStep/timeSubStep (C++ vs C-api, same thing): A fixed time step (typically 1/60 second) which is the actual step used by Bullet internally and help stabilize simulation. Variable timestep is usually not recommended because it causes stability issues in many cases, but since Blender already has a fixed, frame-based timestep this doesn't matter.
maxSubSteps: If > 0 then it will perform fixed timesteps adding up to the timeStep count (min(maxSubSteps, (int)(timeStep / fixedTimeStep))), and the remainder is filled by an extra step and then interpolating to the fraction of time remaining. We just use 0 for a "variable" timestep, which is actually just fixed to the Blender substep.

The problem here is that the force value of the RigidBody is temporary and gets reset to zero after each Bullet simulation step. The first (Blender) substep has the correct value set by `rigidbody_update_simulation` (called outside the substep loop), but after that the external force on the body is zero and no further impulse is added. The smaller substep number makes a larger timestep which increases the impulse added in the first timestep. In the remaining substeps the body just coasts at a constant velocity and no further impulse is added. If the force was set correctly in each substep we could expect the smaller per-step impulse to be compensated by the larger step number and the overall impulse over the whole timestep to be the same. So the solution should be to call `rigidbody_update_simulation` for each of the substeps to ensure correct force values. The arguments to the Bullet step function are actually correct ([stackoverflow explanation ](https://stackoverflow.com/questions/12778229/what-does-step-mean-in-stepsimulation-and-what-do-its-parameters-mean-in-bulle)): * `timeStep`: Overall actual time step in seconds. Physical time since `stepSimulation` was last called. * `fixedTimeStep`/`timeSubStep` (C++ vs C-api, same thing): A fixed time step (typically 1/60 second) which is the actual step used by Bullet internally and help stabilize simulation. Variable timestep is usually not recommended because it causes stability issues in many cases, but since Blender already has a fixed, frame-based timestep this doesn't matter. * `maxSubSteps`: If > 0 then it will perform fixed timesteps adding up to the `timeStep` count (`min(maxSubSteps, (int)(timeStep / fixedTimeStep))`), and the remainder is filled by an extra step and then interpolating to the fraction of time remaining. We just use 0 for a "variable" timestep, which is actually just fixed to the Blender substep.

blender-admin commented

2022-06-22 07:37:45 +02:00

This issue was referenced by f4d8382c86

This issue was referenced by f4d8382c86ba760c5fccf7096ca50d6572b208bd

Lukas Tönne commented

2022-06-22 07:57:37 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Lukas Tönne closed this issue

2022-06-22 07:57:37 +02:00

Lukas Tönne self-assigned this 2022-06-22 07:57:37 +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

Regression: Physics force field strength affect varies inversely proportion to physics substeps per frame #98272