Damping Velocity: How Does it Solve Numerical Inaccuracy?

[The-Mad-Lisper]

In an excerpt from Ian Millington's Game Physics Engine Development, the author mentions a "damping" force:
"In our physics engine we could simply assume that there are no forces at work and use [Newton's First Law] directly. To simulate drag we could add special drag forces. This is fine for the simple engine we are building in this part of the book, but it can cause problems with complex systems. The problem arises because the processor that performs the physics calculations isn't completely accurate. This inaccuracy can lead to objects getting faster of their own accord.
A better solution is to incorporate a rough approximation of drag directly into the engine. This allows us to make sure objects aren't being accelerated by numerical inaccuracy, and it can allow us to simulate some kinds of drag. If we need complicated drag (such as aerodynamic drag in a flight simulator or racing game), we can still do it the long way by creating a special drag force. We call the simple form of drag 'damping' to avoid confusion."
He later mentions something along the lines that damping helps conserve energy of the system, but doesn't go into any specifics. How exactly does damping solve numerical inaccuracy when rounding errors do not necessarily cause an increase in a particle's speed? How does it conserve energy?

 

[D H]

He later mentions something along the lines that damping helps conserve energy of the system, but doesn't go into any specifics. How exactly does damping solve numerical inaccuracy when rounding errors do not necessarily cause an increase in a particle's speed? How does it conserve energy?

In the real world, damping doesn't conserve mechanical energy. Like friction, damping is a dissipative force that turns mechanical energy into heat.

In the real world, a ball dropped from a height onto a floor will bounce a few times (maybe more than a few times if its a superball), but eventually come to rest on the floor. There are dissipative forces in the bounce. Drop hundreds of superballs all at once and you'll have collisions between balls as well as collisions between the ball and the floor. But eventually, everything will slow down and all the balls will be at rest on the floor.

Properly modeling a single bounce is hard. Modeling hundreds, all at once, that's very hard. Game physics engines are worried about getting the appearance of the bounces correct, and doing so in apparent realtime on a typical home computer (or tablet nowadays). This means some amount of sacrifice in the integrators and solvers inside the engine. Typically, the sacrifice is to use Euler integration. Euler integration does not conserve energy. Oftentimes, it spirals out of control. The balls bounce higher and higher, smash into one another harder and harder.

Adding a not-quite physical damping is a simple kludge that (usually) keeps things under control.

 

[The-Mad-Lisper]

Typically, the sacrifice is to use Euler integration. Euler integration does not conserve energy. Oftentimes, it spirals out of control. The balls bounce higher and higher, smash into one another harder and harder.

So by Euler integration, do you mean using x=x_0+vdt rather than x=x_0+v{dt}+\frac{1}{2}a{dt}^2?
Also, does the ball gain mechanical energy because the collision detection system flips both the ball's position with respect to the ground and the sign of the vertical component of the ball's velocity without taking into account that negative work must be done to translate the ball upward?

Edit: Corrected above equations.

 

[D H]

An N-dimensional second order differential equation can always be recast as a 2N-dimensional first order differential equation. That can then be numerically integrated to advance state over time. The problem is that this throws out the geometry of the problem. The problem with using geometric integrators is that these don't mix well with the types of problem game engines need to solve. Things collide in games. Simulated people run; their feet collide with ground. Cars drive; their wheels collide with the ground. Bullets fly, etc. There are lots of collisions in game physics. To solve these, the games typically use an LCP (Linear complementarity problem) solver. Those are extra things that need to be integrated, and the result is a big matrix. So geometry of the physics (that Newtonian mechanics is a second order ODE is "geometry") has to be tossed aside.

People who play video games don't have a supercomputer with thousands of parallel CPUs and thousands of GPUs, each with thousands of processors, available to them. This means the techniques must necessarily be simple to get realtime performance.

 

[newjerseyrunner]

I've dealt with this before, it's really frustrating writing code that perfectly describes physics, then dropping an object and having it bounce higher and higher and higher. I solved this issue not by artificially adding a drag, but by forcing my calculations to round down. I only take the 4 most significant digits after the decimal, this introduces "drag" without any special code.