Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to propose a couple of changes that make my life easier. I don't know for certain that they're generally good for all use cases.
1. Fixed timestepping happens on timeSinceLastCalled = -1 instead of 0
In my app, I have a variable time scale. When I set the value to zero, I would expect the simulation to stop. But instead it switches to the fixed time stepping mode.
I can easily get around it by checking if I'm about to pass
timeSinceLastCalled
of zero, but it seems pretty unintuitive and unnecessary, as I think the exception can be made for an impossible time step like "-1", instead of the current "0".It shouldn't break people's code, unless they deliberately passed 0 to the step() function to get fixed time stepping, which seems very unlikely.
Video:
![](https://github.com/camo/67e64c172bcc54bd7f5d5559335e6a6418985d4a54c4b849949d3760ba22105c/68747470733a2f2f696d672e796f75747562652e636f6d2f76692f483365784365734b6e48672f322e6a7067)
2. Reset world time accumulator when simulation is limited by maxSubSteps
When using the
maxSubSteps
limiting variable, the world accumulator keeps growing, and it then causes issues when simulation is limited by themaxSubSteps
value for a while and then comes back to validtimeSinceLastCalled
times, because the simulation needs to catch up and deplete the accumulator by simulatingmaxSubSteps
of frames every step() call no matter what thetimeSinceLastCalled
is.Video probably explains it more clearly. When I try to get back to regular time scale values, cannon simulates 10 subSteps, even though I only want one.
I'm not sure if this is just my use case or if people use this feature in a different way, where this behaviour is fine. I do know that ammo.js (Bullet) works like my proposed solution, as the issue didn't exist when I ran on ammo.
Video:
![](https://github.com/camo/2531898293eeb39707220f409da77aa1bae6111f912ce59167a90c511aa1e443/68747470733a2f2f696d672e796f75747562652e636f6d2f76692f5343796b68385a686876492f322e6a7067)