Timing, frame-rate consistency improvements and features #777

liabru · 2019-09-01T14:42:46Z

Features

improves general consistency of results between different timesteps based on 60hz as a baseline
changes Body.setAngularVelocity and Body.setVelocity functions to be timestep independent
adds timestep independent Body.setSpeed, Body.setAngularSpeed, Body.getSpeed, Body.getVelocity, Body.getAngularVelocity
adds optional updateVelocity argument to Body.setPosition, Body.setAngle, Body.translate, Body.rotate
removes correction from Engine.update as it is now built in
changes examples to be timestep independent

Notes

When using a fixed timestep of 60hz (~16.666ms engine delta) results should look similar to before, as this was taken as the baseline.

If you're using a non-fixed timestep or one other than 60hz (~16.666ms) results should now become more similar to the 60hz baseline, therefore you may need to adjust e.g. body and constraint properties.

Since Body.setAngularVelocity and Body.setVelocity are now timestep independent, you may need to adjust code you may have been using that factored in the timestep.

For timestep independence, the Matter.Body speed and velocity related get / set functions now relate to a fixed time unit rather than timestep, currently set as 1000/60 for easier backwards compatibility at the baseline 60hz.

Note that Body.applyForce naturally still remains timestep dependent as before, see the updated Body.applyForce docs for details.

While the properties body.velocity and body.speed (and angular versions) still exist they are not typically recommended for user code, in most cases you should switch to the new Body.getVelocity and Body.getSpeed as they are timestep independent.

Examples have been updated to be timestep independent, as well as using the new functions.

Requesting reviewers, testers and comments

If anybody has any time to help me test this update out further and feedback any issues, it would be greatly appreciated:

try experiment with the standard examples in different environments (browsers, devices)
- consider friction, air friction, restitution, sleeping, collisions, constraints
compare these to using the previous version of Matter.js (e.g. see the demo), results should be very similar or better
try this branch with your code base (e.g. use the alpha build on this branch)
try using different delta values in Engine.update (more than 33.333ms won't be stable)
try using engine.timing.timeScale (as another way of modifying delta)
try out the new updateVelocity, body velocity and speed setters / getters

Highlighted changes

Added readonly body.deltaTime
Added delta property to engine update event
Added delta argument to various internal functions
Changed timeScale argument to use delta instead on various internal functions
Fixed issues when using an engine update delta of 0
Improved time independence for friction, air friction, restitution, sleeping, collisions, constraints
Removed optional correction argument from Engine.update
Removed correction and timeScale from Body.update and Matter.Runner
Added updateVelocity argument to Body.setPosition, Body.setAngle, Body.translate, Body.rotate
Added Body.setSpeed, Body.setAngularSpeed, Body.getSpeed, Body.getVelocity, Body.getAngularVelocity
Changed Body.setAngularVelocity and Body.setVelocity functions to be timestep independent
Changed examples to be delta independent

Added delta property to engine update event Added delta argument to various internal functions Changed timeScale argument to use delta instead on various internal functions Fixed issues when using an engine update delta of 0 Improved time independence for friction, air friction, restitution, sleeping, collisions, constraints Removed optional correction argument from Engine.update Removed correction and timeScale from Body.update and Matter.Runner

…y.translate, Body.rotate Added Body.setSpeed, Body.setAngularSpeed Added Body.getSpeed, Body.getVelocity, Body.getAngularVelocity Changed all velocity functions to be time independent

wmike1987 · 2019-10-24T20:04:27Z

I just bought a 144 hz monitor so I'll be testing this branch asap.

Edit: At first glance, simulations now appear much more consistent between 144hz and 60hz for me. With previous versions, the physics varied quite a bit. Will continue to use this branch to see how it behaves and will post updates here.

wmike1987 · 2019-11-06T02:01:46Z

@liabru, any update on how this branch looks to you?

getkey

This is amazing! I received some complaints from users on a 144hz monitor that my game was broken, and this branch fixes every issue.

One thing though, applyForce doesn't take into account frame rate, so I am multiplying the force I want by (1000/60)*currentDelta. In a way, it's kinda nice because it allows me to set anything I want as the currentDelta (I'm using a similar method as you here). But it might not be super intuitive that you have to do that.

I need to do some more testing but I'm seriously considering using this branch on my live game.

getkey · 2019-11-14T17:01:42Z

src/core/Common.js

@@ -10,6 +10,7 @@ module.exports = Common;

 (function() {

+    Common._timeUnit = 1000 / 60;


It would be great if this property dropped the _. There are some cases where I use it to make Body.applyForce framerate insensitive.

Example from my code:

// deltaAdjustment is Common._timeUnit divided by the smallest delta over the last 30 frames // (I'm using something similar as your Runner.tick here https://github.com/liabru/matter-js/blob/82bb41535b09e02dd76a20d5955fc7b4102487d6/src/core/Runner.js#L132) const recoilFactor = -(body.mass * 0.09) * deltaAdjustment; const recoil = Vector.mult(norm, recoilFactor); // recoil Body.applyForce(playerControlledBody, playerControlledBody.position, recoil);

The reason is that it's an internal constant so your code shouldn't rely on it. Body.applyForce now accounts correctly so I guess you won't need it?

getkey · 2019-11-14T17:11:11Z

src/body/Body.js

+        body.positionPrev.x = body.position.x - velocity.x * timeScale;
+        body.positionPrev.y = body.position.y - velocity.y * timeScale;
+        body.velocity.x = velocity.x * timeScale;
+        body.velocity.y = velocity.y * timeScale;


The changes you made to the way velocity work broke something in my game. It's a game where you have a character that can shoot bodies while moving. I want the speed of the bullet to be the addition of the speed of the character and a force at which the bullet is thrown. I was doing this by:

making a bullet body

setting the velocity of the bullet to the velocity of the character

applying a force to "throw" the bullet

Obviously, as you warned here, I shouldn't have done it this way, so it's okay that it broke (I'm doing it properly now 😛 ). But I thought you might want to know. 🙂

getkey · 2019-11-14T18:56:38Z

src/core/Engine.js

     */
-    Engine._bodiesUpdate = function(bodies, deltaTime, timeScale, correction, worldBounds) {
+    Engine._bodiesUpdate = function(bodies, delta) {
        for (var i = 0; i < bodies.length; i++) {
            var body = bodies[i];

            if (body.isStatic || body.isSleeping)


The deltaTime of the static and sleeping bodies do not get set. So if you are doing getVelocity on them you'll get NaN.

Good point, I think this should be fixed now with the initial value for body.deltaTime?

liabru/matter-js#777

wmike1987 · 2019-12-06T19:36:54Z

@liabru , any update on this branch? Would you like some help resolving some of the above comments?

getkey · 2019-12-24T00:26:55Z

I am now updating my physics at a fixed timestep so I am no longer using this but FYI there seems to be something wrong with the frictions. Bodies were sliding much faster on a body with friction set to 0 at 144Hz than at 60Hz.

wmike1987 · 2020-01-30T00:05:14Z

@getkey

Are you also doing the interpolation as described in that article?

wmike1987 · 2020-01-30T02:58:26Z

@liabru , similar to @getkey , I'm also seeing significant differences from friction-air on bodies between 144 and 60 hz. 144hz appears to apply friction more than 60hz.

getkey · 2020-01-31T15:52:41Z

@wmike1987 yes, my implementation is strongly inspired by https://github.com/IceCreamYou/MainLoop.js

I wish I could have used MainLoop.js directly but it didn't fit nicely in my ECS-based architecture.

* master: (32 commits) fix lint update dependencies Revert "Merge branch 'pr/526'" Revert "Merge branch 'pr/527'" changed alpha build configuration add window global, stub require and handle bad values in test tools added overlap metric to test tools fix path to build in test worker implemented threaded comparison testing fixed plugins in compare Added build comparison tools and tests Added config and test files to lint Set loose build version on dev server Added watch content base to dev server added timing to engine snapshot updated readme added tag push to release task updated readme removed yuidocjs dev dependency removed unused gulp release tasks ... # Conflicts: # src/collision/Resolver.js # src/core/Engine.js

hubertgrzeskowiak · 2022-05-28T07:23:58Z

These changes seem to finally fix velocity being framerate dependent. Any chance to merge this to master soon?

* master: increase overlap test updates added readme note about vue watchers increase test timeout remove travis config added ci workflow action

photonstorm · 2022-09-02T12:31:49Z

@liabru I see you're still working on this, from time to time - are there any plans to merge it into master? I think a lot of people are waiting for this :)

liabru · 2022-09-02T14:19:23Z

@photonstorm that's the plan, a major goal was to get constraint stiffness and friction to be consistent across deltas, which I think is now working nicely. Did you try it out at all?

happy-unicorn · 2022-09-13T11:58:31Z

@liabru Hi, any chance to merge this to master soon?

photonstorm · 2022-09-13T14:11:52Z

@photonstorm that's the plan, a major goal was to get constraint stiffness and friction to be consistent across deltas, which I think is now working nicely. Did you try it out at all?

Not yet, but I'm working on the 3.60 release of Phaser right now, so would love to have this merged in! I'll try it out next week with our set of examples - if those all work without issue, that would be a really healthy sign.

sebsowter · 2022-09-14T00:41:58Z

@photonstorm that's the plan, a major goal was to get constraint stiffness and friction to be consistent across deltas, which I think is now working nicely. Did you try it out at all?

Not yet, but I'm working on the 3.60 release of Phaser right now, so would love to have this merged in! I'll try it out next week with our set of examples - if those all work without issue, that would be a really healthy sign.

Looking forward to the merge! I have a few games that are crying out for this update.

photonstorm · 2022-11-22T00:36:09Z

@liabru I don't suppose there's any chance of you merging this into master, is there? :) I really think it could be beneficial!

liabru · 2023-02-11T18:33:48Z

Look out for these changes in the next release. Thanks again to all those who provided feedback here!

liabru added 5 commits September 1, 2019 12:21

Added updateVelocity argument to Body.setPosition, Body.setAngle, Bod…

db8b73f

…y.translate, Body.rotate Added Body.setSpeed, Body.setAngularSpeed Added Body.getSpeed, Body.getVelocity, Body.getAngularVelocity Changed all velocity functions to be time independent

Changed examples to be delta independent

d7e4f58

Added substeps feature to Matter.Runner

516494e

updated edge build

fba5af2

This was referenced Sep 1, 2019

fix air friction calculation #669

Open

understanding delta in Engine.update #148

Closed

liabru added 2 commits September 1, 2019 16:57

added clamping to position resolver damping

7c6cda0

updated edge build

f5311a6

getkey approved these changes Nov 14, 2019

View reviewed changes

getkey suggested changes Nov 14, 2019

View reviewed changes

dvdbrink added a commit to madmultimedia/phaser that referenced this pull request Nov 15, 2019

Matter timing improvements

ba70ec4

liabru/matter-js#777

dvdbrink added a commit to madmultimedia/phaser that referenced this pull request Nov 19, 2019

Matter timing improvements

e9f6587

liabru/matter-js#777

liabru mentioned this pull request Mar 6, 2020

Engine.update : Hardware independent stable time calculation Proposal #818

Closed

liabru added 2 commits March 10, 2020 23:43

revert edge build

e29d03b

liabru added discuss improve need-test labels Mar 11, 2020

liabru added 4 commits March 11, 2020 23:47

fix issues with engine event.delta

6f5af77

change Body.applyForce for timing, add initial body.deltaTime

3117dfd

fix lint

298e3e4

updated alpha build

85ff776

liabru added 8 commits July 27, 2022 20:51

improve Matter.Body docs for functions and properties including readonly

85a9eb2

improve Matter.Engine docs

50fc8f2

remove unused delta params

a572968

improve delta factors in resolver and constraint stiffness

07d13fe

Merge branch 'master' into timing-improve

1b4e288

* master: increase overlap test updates added readme note about vue watchers increase test timeout remove travis config added ci workflow action

improve slingshot example constraint

c6a1a6d

improve delta factors in resolver and constraint stiffness

9dc6be7

clamp resolver slop

ee7b008

liabru added 6 commits September 2, 2022 17:18

refactor Resolver.solvePosition damping argument

cce3152

refactor and tidy

36575b3

rename internal Common._timeUnit to Common._baseDelta

dc46472

refactor body base delta constant

66e291b

move substeps to another branch

db7c4a1

remove alpha build

903228a

change remove example to use timestamps

f8b64b6

liabru mentioned this pull request Nov 26, 2022

deltaTime parameter in Body#update does not work as expected. #1180

Open

liabru added 3 commits December 28, 2022 20:45

revert Body.applyForce

f7da964

improve Body.applyForce docs

3a8264c

update body docs

6bb2855

car1ot approved these changes Dec 31, 2022

View reviewed changes

liabru merged commit b81d6e6 into master Feb 11, 2023

liabru mentioned this pull request Feb 16, 2023

Release 0.19.0 #1196

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Timing, frame-rate consistency improvements and features #777

Timing, frame-rate consistency improvements and features #777

liabru commented Sep 1, 2019 •

edited

Loading

wmike1987 commented Oct 24, 2019 •

edited

Loading

wmike1987 commented Nov 6, 2019

getkey left a comment

getkey Nov 14, 2019

liabru Mar 12, 2020

getkey Nov 14, 2019

getkey Nov 14, 2019

liabru Mar 12, 2020

wmike1987 commented Dec 6, 2019

getkey commented Dec 24, 2019

wmike1987 commented Jan 30, 2020

wmike1987 commented Jan 30, 2020

getkey commented Jan 31, 2020

hubertgrzeskowiak commented May 28, 2022

photonstorm commented Sep 2, 2022

liabru commented Sep 2, 2022 •

edited

Loading

happy-unicorn commented Sep 13, 2022 •

edited

Loading

photonstorm commented Sep 13, 2022

sebsowter commented Sep 14, 2022

photonstorm commented Nov 22, 2022

liabru commented Feb 11, 2023

		@@ -10,6 +10,7 @@ module.exports = Common;

		(function() {

		Common._timeUnit = 1000 / 60;

Timing, frame-rate consistency improvements and features #777

Timing, frame-rate consistency improvements and features #777

Conversation

liabru commented Sep 1, 2019 • edited Loading

Features

Notes

Requesting reviewers, testers and comments

Highlighted changes

wmike1987 commented Oct 24, 2019 • edited Loading

wmike1987 commented Nov 6, 2019

getkey left a comment

Choose a reason for hiding this comment

getkey Nov 14, 2019

Choose a reason for hiding this comment

liabru Mar 12, 2020

Choose a reason for hiding this comment

getkey Nov 14, 2019

Choose a reason for hiding this comment

getkey Nov 14, 2019

Choose a reason for hiding this comment

liabru Mar 12, 2020

Choose a reason for hiding this comment

wmike1987 commented Dec 6, 2019

getkey commented Dec 24, 2019

wmike1987 commented Jan 30, 2020

wmike1987 commented Jan 30, 2020

getkey commented Jan 31, 2020

hubertgrzeskowiak commented May 28, 2022

photonstorm commented Sep 2, 2022

liabru commented Sep 2, 2022 • edited Loading

happy-unicorn commented Sep 13, 2022 • edited Loading

photonstorm commented Sep 13, 2022

sebsowter commented Sep 14, 2022

photonstorm commented Nov 22, 2022

liabru commented Feb 11, 2023

liabru commented Sep 1, 2019 •

edited

Loading

wmike1987 commented Oct 24, 2019 •

edited

Loading

liabru commented Sep 2, 2022 •

edited

Loading

happy-unicorn commented Sep 13, 2022 •

edited

Loading