|
|
|
 |
Reply From: |
bmer |
Rigid body dynamics are modelled via the integration of ordinary differential equations. Integration in general, is a tough problem, so engines tend to approximate the solution using a variety of methods, a simple and common one (especially for gaming, where accuracy is not so crucial) being Euler’s method or Verlet’s method (often used in gaming).
Anyway, even sophisticated numerical integration schemes have an issue: its hard to conserve quantities that should be conserved, not due to floating point precision errors, but errors due inherent in approximation (which dwarf floating point precision issues 99% of the time). Some specially designed schemes are better at conserving quantities that should be conserved, but they simply make errors in different ways (even if those errors are smaller), and are much more computationally inefficient.
So the issue is approximation. We can’t get a perfect solution, so we try to get one that’s good enough, but if its only good enough, then its probably missing something, and in this case, it happens to be conservation of energy.
A simple scheme to mostly “fix” this issue is to every so often correct the energy yourself. You can calculate the energy of a bouncing ball as the sum of its potential and kinetic energy: E = mgh + 0.5*mv^2, where m is the mass of the ball, g is the gravitational constant, h is the current height of the ball relative to a fixed reference point, and v is the current speed (not velocity!) of the ball.
E should be a constant, so simply calculate what it is initially. Every so often, correct E so that it remains close to the initial value. Every so often change the ball’s h by a teeny bit, change the ball’s v by a teeny bit, so that E is close to its initial value, but note that a ball’s v can never be greater than V, where sqrt(E/(0.5*m)) = V (assuming that all the energy of the ball is in its kinetic form, so h = 0), and its h can never be greater than H, where E/mg = H (assuming all the energy of the ball is in its potential form, so v = 0). Try to correct E often enough that the changes you make to h and v are imperceptible enough for the player/user (I guess you could even correct it every frame, since it would probably a relatively cheap check?).
Thanks for the insight.
This might be flagged for irrelevance, nonetheless, it is interesting. Having dealt with physics, diff. eqns, and game programming, it seems somewhat strange that game engines (especially 2D ones) have to resort to numerical methods to approximate anything.
Of course there are problems in the real world that need approximations because the differential equations involved are near impossible (pendulum modelling, fluid mechanics)
It’s not my place to critique the methods of design, but something as simple as a bouncing ball seems oddly trivial. Maybe an oversimplification on my part.
nDever | 2017-06-28 18:07
@nDever the bouncing ball problem can seem oddly trivial, and indeed it is for fixed boundary conditions (i.e. the ball is bouncing straight up and down, or even if it is bouncing with some x-direction motion the floor is always expected to be smooth and straight, no curves in it or anything etc.), but usually in games, this is not the case. Floors tend to be interesting, and the ball might be interacting with other balls (many-body interactions tend to be very non-trivial), or other objects, and these tremendously complicate putting down a simple integral equation solving for the ball’s entire motion.
If you know all the boundary conditions ahead of time, and there are no many-body interactions, then you could probably write down a nice solution to the ODE problem, and just use that instead. But I suspect that if you can do that, your bouncing ball situation is pretty boring 
