Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wassfila opened this issue Jan 19, 2020 · 4 comments
Closed

Comments

@wassfila
Copy link

wassfila commented Jan 19, 2020

I really liked that matter.js provided a flexible interface for timings simulation
https://brm.io/matter-js/docs/classes/Engine.html
Matter.Engine.update(engine,delta,correction);

Question : How to fill these delta and correction parameters ?

Answer : I think that these parameters calculation can be automated

And that is once and for all in a way that could be hardware independent and that avoids instabilities on slow machines or after the pages sleeps in the background.
In this way, the simulation will have a similar behavior on all machine 30 fps, 60 fps or higher, as long as the frame rate does not drop below a low limit that is to be configured in the function.

Related issues

Many open tickets relate to this critical point actually:
#816 (Engine.update() with a large delta crashes browser tab)
#795 (Simulation speed too fast)
#754 (Slow Simulation Down After Engine.update()?)
#702 (Timestep doesn't take refresh rate into account)
and maybe more

Proposal

This is my proposal how to perform that, I wish this code or a similar version to it be included in the examples or documentation (I guess I could do that myself in sometime but I start getting feedbacks about it first)
So here is the solution :

let last_run = 0;
let last_delta = 0;

function get_delta_correction(){
    let delta = 1000/60;//default used on first loop only
    let correction = 1.0;//also default for first iterations
    if(last_run == 0){//first run -> no delta, no correction
        const this_run = Date.now();
        last_run = this_run;
    }
    else{
        if(last_delta == 0){//second run -> first delta but no correction yet
            const this_run = Date.now();
            delta = this_run - last_run;
            if(delta > 100){//avoids instabilities after pause (window in background) or with slow cpu
                delta = 100;
            }
            last_run = this_run;
            last_delta = delta;
        }
        else{//run > 2 => delta + correction
            const this_run = Date.now();
            delta = this_run - last_run;
            if(delta > 100){//avoids instabilities after pause (window in background) or with slow cpu
                delta = 100;
            }
            correction = delta / last_delta;
            last_run = this_run;
            last_delta = delta;
        }
    }
    return {delta:delta, correction:correction};
}

function run(){
    const{delta,correction} = get_delta_correction();
    Matter.Engine.update(engine,delta,correction);
}

integration in a full running sample available here
https://github.com/NetworkGraphs/graph2d
live demo
https://networkgraphs.github.io/graph2d/

in commit 2d1b8ad61f there is a log about deltas that can also be uncommented in all other versions.

@wassfila wassfila changed the title Engine.update : Hardware independent stable time calculation Engine.update : Hardware independent stable time calculation Proposal Jan 19, 2020
@anthonygood
Copy link

Regarding my issue (large delta killing the browser), the pertinent line is:

if (delta > 100){//avoids instabilities after pause (window in background) or with slow cpu
    delta = 100;
}

I manually tick the engine but use a similar logic with Math.min(delta, MAX_DELTA). Think this kind of cap would be great in the built-in runner.

@liabru
Copy link
Owner

liabru commented Mar 6, 2020

Thanks for your comments on this. The way timing works is being overhauled in this PR #777 which I hope to revisit now that I have implemented a better way to test these kinds of large scale changes, hopefully it should also cover most of the issues raised here.

@liabru
Copy link
Owner

liabru commented Nov 12, 2023

Closing this thread to refer to updates in #702 on this topic, thanks again for the reports here.

@liabru
Copy link
Owner

liabru commented Jun 24, 2024

As of 0.20.0 there is now built in Matter.Runner support for fixed timestep with high refresh displays see #1300.

Closing this one. Thanks for the report!

@liabru liabru closed this as completed Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants