New physics time scale APIs - 2017.3073 and later

[bjsorrentino]

Hi Corona physics users/fans,

I’d like to mention that two new physics APIs have been added starting in daily build 2017.3073 and later:

1. physics.setTimeScale() - https://docs.coronalabs.com/api/library/physics/setTimeScale.html
2. physics.getTimeScale() - https://docs.coronalabs.com/api/library/physics/getTimeScale.html

These functions allow you to slow down or speed up the physics simulation via a multiplier. This may be useful if you want to simulate things in exagerrated “fast forward” motion, or show a physics “replay” in slow motion… or to just speed up or slow down your entire physics-based game in general.

Have fun!

Brent

[sporkfin]

Awesome Brent, thanks!  I appreciate all the little magical additions that just keep appearing in the SDK 

[sporkfin]

Awesome Brent, thanks!  I appreciate all the little magical additions that just keep appearing in the SDK 

[ninad]

Hi Brent, I’m looking for a way to speed up the physics simulation without changing the results. As a testbed, I’m using the HelloPhysics sample project on the 2017.3135 public release.

I’d imagine increasing the number of physics updates per second would give me what I want. However, setting a lower dt ( e.g. 1/100) via physics.setTimeStep() seems to have no obvious effect on the simulation speed. Is physics.setTimeStep() still supported? What am I getting wrong here?

Setting a higher time scale with physics.setTimeScale (e.g. 10) does speed up the physics simulation but also changes the results. Is this expected?

Any tips on how I can speed up physics without changing the sim results? Can you share more on how exactly setTimeStep() and setTimeScale() affect the underlying Box2D engine?

Thanks,

Ninad.

[bjsorrentino]

Hi Ninad,

Unfortunately I’m not super in-tune with what “setTimeStep()” does internally… that API has never been fully clear to me and I’ve never needed to use it personally. As for “setTimeScale()”, what kind of differences in simulation outcome are you seeing? Vast and considerable ones?

Brent

[ninad]

Hi Brent,

The simulation differences seem to be significant.

Testing physics.setTimeScale(10) in the HelloPhysics sample results in noticeably different behaviour for the falling crate. The crate bounces lower and ends up at the different X position. 

This is just with one falling body. You can imagine how such changes can have a ripple effect when there are multiple physics objects interacting with each other. It can entirely change the gameplay. 

Regarding setTimeStep, I’ve had a hard time figuring it out myself. From the sound of it, I’d expect it to change the frequency with which world->step() is called? Would you, perhaps, point me to someone at Corona who can share more on what setTimeStep does? 

Thanks, Ninad.

[davebollinger]

@ninad

From the sound of it, I’d expect it to change the frequency with which world->step() is called?

i think you get one call to world->step() per frame, no matter what.  i had assumed it was a scaler for timeStep, such that timeStep*timeScale is the actual value passed to world->step().  (i’ve not yet had any reason to use it, so haven’t yet attempted to verify experimentally)

if so, i’d presume they put it in there to make it easier to scale time when using frame-based time steps, so that you could specify for example 0.5 time scale of the real-elapsed-time varying approximation of 30 or 60 fps time step.  (you wouldn’t need it if using a fixed time step, say 1/30, because you could just do the math yourself and reset the timeStep accordingly, but there’s no current way to get Corona’s internal delta frame time)

if it only has the effect of world->step( timeScale*timeStep, viters, piters) then:  YES, large adjustments to it (like 10) would radically affect the integration quality of the simulation (leading to different results).

[ninad]

Thanks, David. It looks like you’re right about it being world->step( timeScale*timeStep, viters, piters). Just tested a couple combinations of timeScale and timeStep with HelloPhysics. As long as their product is the same, I get the same physics results. 

Given this, it’s completely understandable that sim results differ when the timeScale is changed. The adjustment need not even be too much. Even with a factor of 2-3x you can get a noticeably different result if there are multiple physics objects colliding with each other. 

Can someone from Corona kindly confirm that the implementation is, in fact, world->step( timeScale*timeStep, velocityIterations, positionIterations)? And if so, it’d be super helpful if the documentation is updated to spell this out and highlight that changes in physics behaviour should be expected.

All this, unfortunately, still leaves my underlying question hanging though: Is there any way to speed up the physics simulation in Corona without changing the results? Can the frequency of world->step() be changed? 

Best,

Ninad.

[vlads]

Well. Yes. They are simply multiplied. This feature is made to make slight multiplier-like changes to physics playback speed, not to run simulations. Also, you can use setVelocityIterations and setPositionIterations in physics library. Defaults are 8 and 3 respectively. Also, consider setting setContinuous. Good luck!

[ninad]

Hi Brent, I’m looking for a way to speed up the physics simulation without changing the results. As a testbed, I’m using the HelloPhysics sample project on the 2017.3135 public release.

I’d imagine increasing the number of physics updates per second would give me what I want. However, setting a lower dt ( e.g. 1/100) via physics.setTimeStep() seems to have no obvious effect on the simulation speed. Is physics.setTimeStep() still supported? What am I getting wrong here?

Setting a higher time scale with physics.setTimeScale (e.g. 10) does speed up the physics simulation but also changes the results. Is this expected?

Any tips on how I can speed up physics without changing the sim results? Can you share more on how exactly setTimeStep() and setTimeScale() affect the underlying Box2D engine?

Thanks,

Ninad.

[bjsorrentino]

Hi Ninad,

Unfortunately I’m not super in-tune with what “setTimeStep()” does internally… that API has never been fully clear to me and I’ve never needed to use it personally. As for “setTimeScale()”, what kind of differences in simulation outcome are you seeing? Vast and considerable ones?

Brent

[ninad]

Hi Brent,

The simulation differences seem to be significant.

Testing physics.setTimeScale(10) in the HelloPhysics sample results in noticeably different behaviour for the falling crate. The crate bounces lower and ends up at the different X position. 

This is just with one falling body. You can imagine how such changes can have a ripple effect when there are multiple physics objects interacting with each other. It can entirely change the gameplay. 

Regarding setTimeStep, I’ve had a hard time figuring it out myself. From the sound of it, I’d expect it to change the frequency with which world->step() is called? Would you, perhaps, point me to someone at Corona who can share more on what setTimeStep does? 

Thanks, Ninad.

[davebollinger]

@ninad

From the sound of it, I’d expect it to change the frequency with which world->step() is called?

i think you get one call to world->step() per frame, no matter what.  i had assumed it was a scaler for timeStep, such that timeStep*timeScale is the actual value passed to world->step().  (i’ve not yet had any reason to use it, so haven’t yet attempted to verify experimentally)

if so, i’d presume they put it in there to make it easier to scale time when using frame-based time steps, so that you could specify for example 0.5 time scale of the real-elapsed-time varying approximation of 30 or 60 fps time step.  (you wouldn’t need it if using a fixed time step, say 1/30, because you could just do the math yourself and reset the timeStep accordingly, but there’s no current way to get Corona’s internal delta frame time)

if it only has the effect of world->step( timeScale*timeStep, viters, piters) then:  YES, large adjustments to it (like 10) would radically affect the integration quality of the simulation (leading to different results).

[ninad]

Thanks, David. It looks like you’re right about it being world->step( timeScale*timeStep, viters, piters). Just tested a couple combinations of timeScale and timeStep with HelloPhysics. As long as their product is the same, I get the same physics results. 

Given this, it’s completely understandable that sim results differ when the timeScale is changed. The adjustment need not even be too much. Even with a factor of 2-3x you can get a noticeably different result if there are multiple physics objects colliding with each other. 

Can someone from Corona kindly confirm that the implementation is, in fact, world->step( timeScale*timeStep, velocityIterations, positionIterations)? And if so, it’d be super helpful if the documentation is updated to spell this out and highlight that changes in physics behaviour should be expected.

All this, unfortunately, still leaves my underlying question hanging though: Is there any way to speed up the physics simulation in Corona without changing the results? Can the frequency of world->step() be changed? 

Best,

Ninad.

[vlads]

Well. Yes. They are simply multiplied. This feature is made to make slight multiplier-like changes to physics playback speed, not to run simulations. Also, you can use setVelocityIterations and setPositionIterations in physics library. Defaults are 8 and 3 respectively. Also, consider setting setContinuous. Good luck!