Monday, January 24, 2011

ATC Part I - Real Physics

This is a repost of a reply I wrote on avsim that sort of grew out of control. In part II I will try to explain what we're doing with the ATC system and how far we will get in X-Plane 10.0. Anyway, post follows.

I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y'all started under the assumptions that:

The flight model is going to be too expensive to run on AI planes and

A table based flight model would be faster.

Those are both questionable assumptions at best...pretty much everything you can conclude from that is, IMO, dubious.

(I should mention at this point that I am unaware of any "dumbing down" features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)

Here's the short version:

The most expensive part of the flight model is ground interaction - that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is "clearly in the air" (e.g. an initial test shows it has high altitude) the FM isn't very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.

So if we want to make the FM faster, there's really only one place to attack: ground interactions - it's the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes - since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) - that adds up. If we are willing to trust that the AI planes don't screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.

Now what if we did some kind of 'lo-fi' AI, whether it's table based or it simply says "move the plane forward by this much" (E.g. a sort of track-based system)? If we want the airplanes to 'sit' properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM - the wheel-ground collision checks. So the total savings of a 'lo-fi' AI flight model would be very small, because at best we might partly improve the performance of code that doesn't have much impact on the sim.

(To understand why you can only boost performance by attacking the biggest pigs, see here.)

However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time...the time spent building a separate flight model could have been spent performance-tuning the real flight model...even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.

Besides my explanation above of why a lo-fi flight model wouldn't really be a win, two more comments:

In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than speculate how a system may perform and write a ton of code up front before you have real data. This is what we are doing...the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it's going to work reasonably. IF we hit data that says "no we have to do something radical", then we will...when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.

And finally, dude, the real FM looks good. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane's suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you're at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it'll be hard to go back to a 'synthetic' FM.

* This may not be a safe assumption...what if a microburst hits an AI plane?

15 comments:

I noted somewhere (maybe on this blog somewhere) that I'd gladly trade AI physics performance for my own performance...

Even if that's not the case, I'm wondering why the AI physics wouldn't be scalable based on user proximity?

I'm sure landing gear compression on heavies looks great, but if I can't see it, I really don't care.

Try convincing someone that the 8 aircraft taking off 6 miles away are acting super-realistic, physically, while their system bogs down because they want to see trees. I don't think their experience will improve that much by knowing this...

What I'd like to see are 5 or 6 aircraft realistically performing in the air at a small regional airport - some staying in the pattern, some leaving & departing. Something tells me you need to separate flying from taxiing. I can see the value of physics here, somewhat, but not if, at the same time, my system is being slowed because the same thing is happening a few miles away.

Well, maybe I need to go back and read again because I think I must be missing something here.

Hi ben. I completely agree with you. I would love to see some improvements in the FM regarding the Wheel-ground collision system. I think at present it needs some refinement so that taxi, takeoff and touchdowns look more real. The wheel-ground collision should be improved so that tires ACTUALLY sit on the ground properly!. Secondly real FM should handle the AI-Aircrafts. I would love to see how those AI-planes handle some serious crosswind.

Refreshing to hear all of this! One important aspect here is to remember computers evolve very quickly, where a new generation of CPUs/GPUs by far exeeds the performance of their earlier counterparts. Quadcore CPUs are already standard or close to standard in new, medium class, computers. With the latest Sandy Bridge processor there really -is- a bucket load of performance to play with. And one really should. The same goes with GPUs. Even an old nVidia 260 gfx card produces very good framerates in XP.

I find that a part of the XP community are feeling afraid that their 3 year old computer wont run XP. If it was a medium end computer: It sure will! But technology advances and with refined and faster technology we also expect higher quality content to reflect the hardware found in our computers.

There really is not much to add as I am feeling confident the XP team already are implementing sliders with broad intervals in options for graphics, effectively making a huge spectrum of options available to make the simulator look just right for everyone's computer.

Just having bought a new Sandy Bridge computer for XP10 running at 4.5GHz with a GTX580 card and 8GB of RAM all I can say is that on my part I am ready to try out next version of XP. Kudos to ben for keeping us updated with all these details!

If its only 20 then its going to look very poor in comparison to FSX that can handle over 100 on the ground and in the air at one time.

Sure the FSX AI physics is poor compared to what your suggesting for XP10 but who cares when you can land at EGLL with 50 planes sitting at gates and other 30 or so in the air, including some on final and some having just departed.

I think far more people would be impressed with busy airports and realistic traffic levels than with how 'super accurate' the AI flight model is.

I feel that you're using the accurate AI flight model as an excuse for not having realistic AI traffic levels.

XP10 will look a very lonely place if big airports have just a handful (20) of AI aircraft.

I don't know how many we'll support. It might be 20, it might be more. They might be virtualized, they might not be. I will describe how the feature set is planned in more detail tomorrow.

If you set up a check list of FS X vs. X-plane 10 ATC, I can almost guarantee that you will be disappointed; what we will ship in 10.0 will basically be brand new; it will (like the scenery system) take a few patches to mature and develop some of the deeper features.

Using a real flight model is _not_ an "excuse" for 20 planes - it's not an either or trade-off. We didn't go "do we want 20 planes with real physics or 100 planes with some fake physics."

Im sure the XP10 ATC is much better than the FSX ATC, but FSX has 3rd party ATC modules (eg Radar Contact and Proflight) that completely replace the default FSX ATC. I very much doubt the default XP10 ATC comes close to these 3rd party products.

It would be nice if whatever API primitives the default XP10 ATC uses to direct aircraft can be exposed via the plug-in SDK so that 3rd parties can develop their own replacement ATC plugins and turn off the default XP10 ATC.

But also I guess if a XP10 version of SimConnect.DLL could be written then a lot of FSX utilities might work "out of the box" with XP10. Imagine if things such as Radar Contact (http://www.jdtllc.com/) could work with XP10 without changes, just a new XP10 specific version of SimConnect.dll

Ben, does the version 9 AI turn off ground testing when "clearly in the air" as well (which they always are in version 9, I guess), or is this one of the possible future optimizations? Because on a quick test on 9.65, frame rate went from just below 60 without AI to about 25 with 19 AI planes.

Of course, if the flight model will indeed become completely independent of the main thread, I couldn't care less, but in version 9, the AI certainly is a big performance hit (on my first-generation Mac Pro anyway).

Off topic (please feel free to delete the following if you feel it's inappropriate here):

MatthewS, how many FSX add-ons are actually out there that only use SimConnect, without also using FSUIPC or some other IPC mechanism, like the panel SDK? I'm only aware of a very few. And there's already a reimplementation of the FSUIPC interface for X-Plane, in the form of XPUIPC (which is far from complete, but quite usable with a lot of FS9/X add-ons).

MatthewS: FSX 3rd party ATC modules won't be anywhere near the XP-10's ATC. I don't want to start an FSX vs XP10 discussion here but I guess you are one of those whoe just want to see the eyecandy and not the realism. AI-Aircrafts will be handled by the real flight model and you can ACTUALLY see them suffer when there is some turbulence or crosswinds or gusts. I think BEN can explains this in more detail.

"Because on a quick test on 9.65, frame rate went from just below 60 without AI to about 25 with 19 AI planes."

Quick follow-ups:- In v9, the AI planes don't ever taxi, so you can't measure the cost and/or optimization of ground contact in v9. (In fact, ground contact costs are very low with lots of AI planes because they don't taxi.)- In v9, foil-airstream calculations dominate the FM when a plane is in the air - 17% of CPU with 20 planes on my machine. (In this configuration, total FM takes 50% of CPU, so you can see how multicore is a big win here.) I believe Austin has already restructured the code to be faster in v10.- Scenery checks are always there - 5.5% of CPU time spent checking for ground height in the autopilot AI as it tries not to crash into things. (This relatively high cost for a simple collision check is partly because the spatial coherency is bad, which causes collision cache thrash.)