Board index FlightGear Support Flying

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

Controlling your aircraft, using the autopilot etc.

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

Postby nixnerd » Sun Dec 01, 2019 1:30 am

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.
nixnerd
 
Posts: 14
Joined: Sat Feb 17, 2018 1:39 am

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

Postby V12 » Sun Dec 01, 2019 11:08 am

Time accel more than 8x is risky in all sims.
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 1607
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

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

Postby tdammers » Mon Dec 02, 2019 12: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.
tdammers
 
Posts: 233
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

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

Postby Thorsten » Mon Dec 02, 2019 1:08 pm

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
Thorsten
 
Posts: 11196
Joined: Mon Nov 02, 2009 8:33 am

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

Postby nixnerd » Tue Dec 03, 2019 12:30 am

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 :)
nixnerd
 
Posts: 14
Joined: Sat Feb 17, 2018 1:39 am

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

Postby tdammers » Tue Dec 03, 2019 10:33 am

Thorsten wrote in Mon Dec 02, 2019 1:08 pm:
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.
tdammers
 
Posts: 233
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256


Return to Flying

Who is online

Users browsing this forum: No registered users and 1 guest