by tdammers » Mon Dec 02, 2019 1:48 pm
Don't use time warp for anything important.
The problem has to do with how FDMs usually work. Real aircraft move in a continuum, but we can't do that in a computer; we need to slice time up into discrete chunks, and calculate what happens between them. This process is called "integration", and most of the viable approaches to that depend on the duration of each time slice (the "time delta" or "delta-t") to be small (and ideally constant, though that is a secondary concern). The problem, now, is that the processing power needed for each time slice is roughly the same no matter how long it is, because the integrator tends to simplify things such that most values can be calculated by linear interpolation (e.g., newPos = oldPos + velocity * deltaT); but smaller time deltas means we need to calculate more updates per second in order to keep up. Larger delta-t, however, leads to loss of accuracy - e.g., if we approximate an accelerated movement by first adding accel * deltaT to the velocity each frame, and then adding velocity * deltaT to the position, then we actually get a series of linear movements rather than a proper smooth accelerated movement, and the larger we make our deltaT, the larger the error.
At 1x time warp, this usually works out, because the FDM has been tuned to perform well at time deltas that can realistically be maintained on today's hardware - they make all sorts of compromises such that we can comfortably calculate 120 simulation frames per second without falling behind, and the FDM has also been designed such that all the integrators remain stable (i.e., they behave like they should) at that frame rate. But if we're going to speed things up, we are faced with a tough choice: we can keep the simulated frame time the same, which means we need to calculate more simulation frames per second - at 8x acceleration, instead of 120 frames per second, we now need to calculate 960 frames per wall-clock second to maintain 120 frames per simulated second. Most likely, the CPU won't be able to keep up, so that's not really an option. So instead, we have to increase deltaT. But this comes at the expense of simulation quality, and our integrators, fine-tuned and tested for the 120 fps scenario, will now, at 8x time warp, run at a rate of 15 frames per simulation second. At best, this gives you slightly unrealistic flying behavior; at worst, it causes things like autopilots and such to go unstable, throwing them into a wild oscillation. The same can happen to all sorts of other things, including the aerodynamics simulation.
Now, there are integrator algorithms that can deal with arbitrary delta-t, but those won't really help either, because for those, the required computation power at least partially depends not only on the number of frames, but also on the movements themselves, so we're not really winning anything - if we're going to speed those up, we'll still have to do more work in the same amount of time. They also tend to be a lot more complex, and more difficult to implement, than the simpler integrators that people typically use in flightsims.