I have a 2 hour flight in a Cessna 172 ahead...

[nixnerd]

I have a 2 hour flight in a Cessna 172 ahead, that I plan on streaming or recording, for a friend to view. However, I've noticed that the time warp thing in Flightgear seems to be wildly unreliable at high speeds, e.g. 16 or 32 times, and causes my plane to plummet from the sky, without warning. I'm keen to gather input from all you other virtual aviators, as to how I might do this, while still enabling some kind of immersion factor and experience, to show my friend.

[V12]

Time accel more than 8x is risky in all sims.

[tdammers]

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.

[Thorsten]

Now, there are integrator algorithms that can deal with arbitrary delta-t, but those won't really help either,

Which is known as the 'There's no free lunch' theorem.

[nixnerd]

Thank you for your input, gentlemen, I will ensure I have a packed lunch/supper/breakfast and suitable liquid refreshment available, to enjoy slow, leisurely flight

[tdammers]

Now, there are integrator algorithms that can deal with arbitrary delta-t, but those won't really help either,

Which is known as the 'There's no free lunch' theorem. :D

Yep. Though in some scenarios, the tradeoff can be worth it. I once wrote a little 2D top-down space dogfighting game that did exactly this - rather than integrate at a fixed rate, it would merely accept control inputs at fixed intervals; it would then calculate the trajectories of all objects in the scene to find the next collision or control input, forward the simulation to that point, handle the collision, and repeat this process until reaching the end of the current time slice. This was possible because the physics were fairly simple - mostly just linear and constant-acceleration movements in an idealized vacuum, and only sphere-sphere and sphere-line collisions, and it allowed me to achieve high frame rates and correct collision detection and response at extremely high velocities - spaceships would achieve speeds so high that they could easily cover 10 times their own size in a single rendering frame - a simpler stepwise integrator with a collision detection that merely checks whether two objects are currently overlapping would have required integrating at rates upwards of 500 fps, which is absolutely bonkers if you consider that the scene graph is populated sparsely, so out of those 500 frames, maybe one or two would actually have a collision, but you'd still check all the objects 500 times.

But that's not going to work for a flightsim, because most movements aren't linear or continuously accelerated; aerodynamics is way too complex to get away with that, and doing all the FDM math in such a parametric fashion while at the same time keeping rounding errors and other numeric instabilities at bay seems like a daunting task to me.