Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid spiral of death when physics step get more time than rendering + add physics to frame profiler. #144
Avoid spiral of death when physics step get more time than rendering. When there are more than 5 steps per Update, next steps are abandoned and time reduced. Don't know how big should be default value, you can change it if you think it is too low/high.
This value can be changed by
Physics is in frame profiler now:
Note from Andrzej, not to forget: look at Bullet's solution for this, similar to this PR, in https://github.com/bulletphysics/bullet3/blob/master/src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld.cpp
michaliskambi left a comment
I add some suggestions. In particular, maybe we can avoid slowing down the simulation to avoid the "spiral of death"? I propose some solution in the comments. Please test if see if my proposal makes sense :)
Note that Bullet does it exactly like you propose. So my proposition may very likely be wrong :)
Why did I abandon the idea of taking the last long step to better synchronize physics? (I thought I wrote about this on discord, but maybe I forgot.)
From my understanding of how the physics engine works (still many things are incomprehensible to me, so maybe I am wrong then please somebody correct me). When the physics step takes place, new positions of physical bodies are recalculated, then collisions are checked and possible positions/velocities corrected. So I think there can be a lot of issues when the time will be not fixed.
E.g. if we have a ball and a brick (as in my game ;)
There are no problems here, in the next steps of physics the ball approaches the brick and when their positions overlap the engine detects a collision.
But there may be problems with fast-moving bodies, engine may "miss" the collision because in the next frame of physics the ball will be far behind the brick:
That's why, intermediate steps (continuous collision detection) are used for such objects:
Engine calculates intermediate steps to detect collisions. When the period of time between the steps of physics is constant it is easy to tell at what speed the body should be set as continous.
BTW. We haven't implemented continuous collision detection yet, but Kraft has it and I plan to do it in the next PRs.
I think that with a long step of physics there will be same problem as with fast bodies. In some situatuions the engine can calculate new position of ball far away from the curent one. And strange errors could occur, e.g. falling out of the level, etc.
I think losing this time in physics is not such a big problem. Usually it happens when loading a level or when the system does something in the background. For example when you install 50 updates on android phone you can notice that :)
I checked Bullet source code later and treated their approach as a evidence for you ;)
OK, I understand that. I see in both approaches we have some disadvantages, the question is which is worse:
I feel persuaded by your comments (and the fact that Bullet does it). So let's go with it, OK.
(At least until we can use Kraft's continuous collision detection. Then I think my solution would be better.)
Indeed you explained it very nicely in your comment. I suggest you place a link to it in the implementation, like