Game Development Reference
In-Depth Information
and examples in this topic do, there will always be artifacts. These artifacts are
not results of a problem with the physics engine itself, but the assumptions and
approximations the engine is built upon. This is important to realize, because
once you accept the artifacts and understand their underlying causes, it makes
them easier to deal with and work around.
2.3 Time Stepping and the Well of Despair
Since the physics engine is advanced in discrete steps, what happens if the game
drops a frame? This is a common source of confusion when integrating a physics
engine, since you probably want the motion in your game to be independent of
frame rate. On a slow machine, or in the occasion of your modern operating sys-
tem going off to index the quicksearch database in the middle of a mission, the
graphical update might not keep up with the desired frequency. There are several
different strategies for how to handle such a scenario from a physics perspective.
You can ignore the fact that a frame was dropped and keep stepping the normal
step length, which will create a slow-motion effect that is usually highly unde-
sirable. Another option is to take a larger time step, which will create a more
realistic path of motion but may introduce jerkiness due to the variation in dis-
cretization. The third option is to take several, equally sized physics steps. This
option is more desirable, as it avoids the slowdown while still doing fixed-size
time steps.
2.3.1 The Well of Despair
Making several physics updates per frame usually works fine, unless the physics
is what is causing the slowdown to begin with. If physics is the bottleneck, the
update frequencywill go into the well of despair, meaning every subsequent frame
needs more physics updates, causing a slower update frequency, resulting in even
more physics updates the next frame, and so on. There is unfortunately no way
to solve this problem other than to optimize the physics engine or simplify the
problem, so what most people do is put a cap on the number of physics updates
per frame, above which the simulation will simply run in slow motion. Actually,
it will not only run in slow motion but it will run in slow motion at a lower-than-
necessary frame rate, since most of what the physics engine computes is never
even shown! A more sophisticated solution is to measure the time of the physics
update, compare it to the overall frame time, and only make subsequent steps
if we can avoid the well of despair. This problem is not trivial, and there is no
ultimate solution that works for all scenarios, but it is well worth experimenting
with since it can have a very significant impact on the overall update frequency.
Search Nedrilad ::




Custom Search