EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

X-Plane 11.10 beta 5 is here, and a before and after says it all.

Tyler heard your pain (as did the rest of us, as we received approximately 8,414,493 requests to kill the FPS nag) and we have changed the low frame-rate warning from the perpetual flashing “you’re too slow” shown on the left to the pop-up warning on the right. And if you like flying a slide show, you can click “don’t show this again” and … we won’t!

The new warning is a bit more conservative – you should only see it if you’ve got persistently low framerate – a transient dip due to texture paging should not make it pop up. If you see it appearing spuriously, please file a bug. In these pics I’ve set my poor 3-year-old iMac to maxed out AG, maxed out shadows and maxed out shaders all at once with the 747 to dip below 20 fps.

The rest of this post discusses the “why” behind this dialog box.

X-Plane Requires 20 fps (or: How Did We Get Here)

X-Plane has some fundamental rules about how it simulates flight – these are our design parameters.

  1. X-Plane simulates one physics frame and renders one graphics frame in lock-step – physics and graphics do not run independently.
  2. X-Plane’s physics model will not “step” the simulation forward more than 50 ms in each step, to avoid computational flutter and other flight dynamics problems.*
  3. X-Plane allows you to set your rendering settings as high or low as you want, even if you don’t have hardware that can render a graphics frame at those settings in 50 ms.

If you consider all of these things, you can see the problem. You can crank up your settings on an old machine and the rendering engine needs more than 50 ms but the physics engine won’t simulate more than 50 ms in a single step.

X-plane does the only remaining option: if your computer cannot sustain 20 fps rendering, your flight will be simulated slower  than real time.  For example, at 10 fps, a flight from Boston to JFK will take 90 minutes, not 45.

It turns out that lots of X-Plane users don’t know about this behavior, and as a result, Austin receives a steady stream of emails complaining that the sim is unrealistic because en-route times are too long – virtually all of them are caused by low fps.

So for 11.10, Austin did what Austin does: he put a big loud message on screen to tell users that they were below real-time simulation.

We Should Probably Say Something

The result of this message was not users going “oh, I’ve learned something, I’ll turn down my rendering settings.” It was a huge number of bug reports that X-Plane 11.10 had catastrophically worse FPS than X-Plane 11.05. In many of these cases, users thought they were getting 20 fps because the flight model reads 20 fps in the time window data output (a very confusing display) and there is no bitch-o-gram.

I considered the option of just nuking the message a second time, but there may be problems with running at low fps that users don’t realize. For example, if you’re on VATSIM doing 170 knots on final like the controller asked at 10 fps, you’re doing…85 knots and your 737 is looking a lot like a C172.

So we went with Tyler’s popup + never-show-again design; it brings the issue of low fps to the surface, but lets users dismiss it forever if they can live with non-real-time simulation.

Why Don’t You Just Split the Physics and Graphics

When discussing this with users I did get asked a lot, “why don’t you run the physics and graphics independently so we can run in real-time at < 20 fps”.  There are a few reasons why we did not (and are not) considering this approach.

  1. Separating the execution of the physics and graphics code would require significant engineering work – right now they run in an alternating pair, and therefore they don’t need to be coordinated at all. Once they run independently, a bunch of new code is needed to mediate their interaction.  That engineering time would take away from just making X-Plane faster.
  2. The cost in CPU time of coordinating the independent FM and graphics would not be free, so this would make the actual frame-rate for the sim worse in pretty much all cases.
  3. Our goal is to make X-Plane run at 60 fps, and we consider 20 fps (the minimum) to already be really quite awful. So we really want to focus on making X-Plane faster, not on making it work better at a frame-rate where the user experience is very sub-standard.

So we’re going to keep focusing on performance optimization that will benefit everyone and not take a side-tangent into making 15 fps flight run in real-time.

 

* If the time between frames is too large, self-damping forces on the aircraft and feedback-based control systems will not react properly because they will not respond quickly enough, due to there being no simulated frame shortly after a large force is introduced.  The result can be incorrect handling at the outside of the flight envelope, for example.

 

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

114 comments on “X-Plane 11.10 Beta 5 – Ding Dong, the FPS Nag is Gone (Mostly)”

  2. I think the new warning is better actually, it puts it in plain simple words. you are not running in real time with these settings. Now when someone complains about frame rates, and they’ve gotten or turned off this warning. its on them.

  3. Thank you for allowing us to kill the birds again!! The other day I tried twice to takeoff from Rome… First time dual birdstrike, complete thrust loss, RTO. Second attempt, one engine down… In the beginning it’s “fun” because other simulators don’t have this… but after a short while it gets really frustrating and annoying…
    Maybe some day we can adjust the likeliness of getting a birdstrike from “every other takeoff” to “very rarely”?

    Cheers 🙂

    1. Oh, disregard, the birds are still there, I heard 🙁

      Hope this gets “fixed” again soon.

      Thank you.

  4. Thank you Ben,
    I’ve been with you guys from the very beginning and I must say this is a real eye-opener! Does increasing flight models for frame affect all this? I often have to run 3 to 5 flight models per frame. I always thought the program use concurrent processes, rather than the serialized approach. With that in mind, I think it might be the reason why formation flying in Xplane online is so problematic. I used to believe it was net code issues. Now I’m starting to rethink that. And I’m going to look at this whole FPS flight model calculation issue. Which I believe could explain why 2 aircraft flying the same airspeed. Cannot fly together or worse 2 identical aircraft one slower but in the lead and one faster but trailing and yet the trailing aircraft can never catch the one in the lead. As I said, a real eye-opener. I know you said you don’t have plans to separate the processes. but I think at some point you’re going to have to. it was my understanding you are multithreading, is that not the case?

    1. Multiple aircraft are concurrent with each other.
      Some rendering tasks are concurrent with each other.
      Background loading is concurrent with everything.
      But per frame it’s a day-shift and a night-shift (each multi-threaded) that get out of the way of each other between the physics and graphics.

      Increasing the iterations per frame does improve flight stability and does make the FM more expensive, but we still don’t lower the minimum fps.

  5. Ben,

    Would you please tell us what is behind “11.10 Flight model changes are now opt-in when the .acf is re-saved in 11.10 Plane Maker.” ?

    MC

      1. Waiting for the post on the subject, please confirm that the opt-in is not applicable to the default Laminar aircraft; they surely would benefit from Austin’s model changes and already incorporate them in the 11.10 beta 5 acf without need to re-save, right?

    2. Saving my default C-172 (in both the default and the REP versions) in Plane Maker has solved my “fail to follow the line” in the GPS problem. Ground handling also seems to have improved.

      Thank you Ben for a beta (b5) that flies like a final version. You guys are the best.

  6. Why aren’t we getting these betas on Steam? It’s still b3 there. You should update Steam when you update the non Steam version. This sucks. You are treating Steam customers as trash, if you ask me. We paid for X-Plane too.

    1. I don’t want to be unfair, but steam users are generally less tech savvy. After all, steam simplifies the installation process a lot and it’s simply “click and play”. Which also means, steam users would be a lot less happy if they update and suddenly the simulator doesn’t start at all. I believe that is the reason why betas in steam are delayed.

      1. That thing about less savvy is nonsense. I and some friends of mine fly simulators since the first FS. I even run a flight simulation website and develop sceneries. I doubt you are more savvy than I am. I bought on Steam because it was a bit cheaper, but if I knew there would be this difference in the updates I wouldn’t have bought on Steam. The updates should be on Steam at least the day after the regular version updates. Steam customers are not forced to use betas, they have to enable them to use them. So the “steam users would be a lot less happy if they update and suddenly the simulator doesn’t start at all” doesn’t make any sense too.

        1. Why did you have to take what I said personally? Of course there are plenty of tech savvy users on steam. I like to think I am one of them. I meant on AVERAGE.

          But if you didn’t know that steam gets delayed updates, maybe you are not so tech savvy… or at least not as informed 🙂

    2. This has been expanded on here before.

      It takes extra work to publish it on Steam. This doesn’t make a lot of sense to invested developer time into if it turns out the beta ends up needing a fix to – for example- not crash for every 2nd AMD user.

      They’ve said they should be able to publish betas to Steam more frequently, so I’m sure you’ll see this one (or the next one?) soon.

      And keep in mind that you do have X-Plane after paying for it, and you do get betas. Saying Steam customers are treated as trash really isn’t helping. Keep in mind Steam customers are also the ones to get rare discounts!

      1. We probably should have gotten b4 out on Steam … I didn’t ask Philipp to go push it because we’ve been tracking piles of flight model issues, so I never stuck my head up and went “This is kind of stable.”

        If b5 is considered stable by the time Philipp gets back from FSWeekend we’ll push that.

        1. So, 3 more days without being able to fly the bell 429 which crashes the simulator with B3 and without being able to use the RealityXP GTN 750 without problems. Nice.

          1. It’s. A. Beta.

            It is, by it’s very definition, full of bugs — bugs we know about! If we thought it was debugged enough for our users to use, we would have called it a release candidate.

            If the problem with the beta is that your favorite add-on is broken, please go back to 11.05.

          2. You should NOT use X-Plane Betas if you just want to fly. You should only use them if you want to actively help Laminar finding bugs.

            The term “beta” has become very fuzzy over the last years with many software, so most people assume “Beta = just a few glitches but ok”. But it has a clear meaning with XP: “Beta = unstable, breaks many things, really just for testing”. This has also been explained many times both by Laminar and in forums.

          3. Replys like this Al, is why everyone is hesitant to put beta on steam. Dont use Beta for enjoyment. Beta is for testing. With steam you can not run 2 installations so you shouldnt even think about running beta.

            Xp 11.05 is totally stable and works fine just use that.

        1. Se esta irritando não leia, e possam ir comer repolho com batatas. E se te irrita com dialelos não se escute.

    2. Definitely. With fries and a can of soda. Takeaway, thank you.

      (this *is* an international forum; please do not make it impossible to read for tons of people by deviating from the “lingua franca” (heh) => “english”)

  8. Thanks Ben, very informative post as always. I think this option with the dialog box (and the ability to permanently to turn it off, plus the 1 minute waiting time), is the best possible option. You not only warning people, but also stop nagging more advanced users who know what they’re doing, and don’t mind the occassional 20fps. It’s so great that this blog exist, because we not only know what is going on, but also get to communicate with the team (well, mostly you).

  9. Here are some community hearsays” for ya Ben

    1. 11.10b5 – FPS is mentioned by several users to have decreased by upwards to 30 fps
    (i7 7700, GTX1080 default installation)
    2. 11.10b5 – FPS is mentioned by to have increased on low-end PC’s
    3. 11.10b5 FPS is mentioned to be way less than 11.05
    4. 11.10b5 FPS is mentioned to be less than 11.10b4
    5. X-Plane 11.05 is mentioned to outmanoeuvre X-Plane 10.51 by having better FPS
    6. X-Plane 11.10b5 is mentioned to have the same performance as X-Plane 10.51

    To sum up:
    11.05 good, 11.10b5 bad when it comes to indicated FPS/performance

    PS, two question for you Ben.
    What is that short startup sound you get with 11.10b5 on finalizing load?

    Also, ask whomever that focus on European autogen if its possible to tone down “apartment block buildings”? Or possible define a rule that says it is more likely to random generate this types of buildings in larger cities rather than in rural areas. As of now the “blocks” outweigh the “houses”

    1. If someone thinks 11.10 is ridiculously slower than 11.05, they can file a bug claiming relative fps loss at a given airport and we can get them a FPS test to run. But so far when Sidney has put people through this the fps loss has been really small and well within what is expected for (1) hardware not benefiting yet from full optimization and (2) us shipping a ton of new art.

      Sound on finalizing load – no idea.

      2. The sound you hear could be the one emitted when the FMOD engine briefly reacts to datarefs initialization until they assume the correct values, happens in most FMOD enabled aircraft.

    2. Tom, most of those higher buildings are not random, nor made up. Usually every OpenStreetmap (See, OSM … not random!!!) “high” building is now represented by a building object with the correct height.

      The height is either derived from the OSM tag (of buildings) “height” OR, if that is not supplied I use the “building:levels” tag and multiply it by 4 (at least now, before it was 4.5) to get an approximated height of the building.

      Then we filter out all of these buildings < 20m … and the rest the gets put into the X-Plane scenery as an object … and then, depending on the randomization in the library autogen, it is represented by different types of apartments.

      Of course there is a lengthy list of what kind of buildings I consider for this height info … like for example I filter out churches etc. as no one wants to see a church represented by a big house block.

      Also, this OSM approach is not perfect, as it – as with everything from OSM – it depends on the OSM data quality. A classic error – for example is – that some guy has the "house no" 100 in his small village … and accidentally sets this as the building:levels (putting a "nice" skyscraper in his town :-)). Or someone thinks, that the attribute "height" is the value at which elevation the building is. Thus adding a 1670m high "hut" on an Alpine meadow.

      Have seen a lot of this madness in OSM and even fixed quite a few of them as I could filter out the worst cases via my GIS program … But as they all need a case-by-case checking, I never can completely clean up (and also, we can't stop OSM users to add even more of this "madness" 🙂 )

  10. I do find that a reboot right before running X-Plane is required to achieve the full FPS rate available (at least on the Mac version).

  11. Hi Ben:
    I read that the objective of the X-Plane team is to run it at 60 FPS, but some Addons are not optimized for X-Plane 11, an example of this is when I fly in a default plane MD80 or B737 the FPS that I get it from 30 to 40, when I fly in a third party product the FPS goes down to 20 or 18, the same thing happens with the scenery.
    The questions are … will the developers have the necessary tools to optimize their products?, and, The users of ATI can enjoy a better performance and when?.
    Regards

    1. I would argue that add-on vendors do have the _flexibility_ with x-plane to achieve high framerate. But they may not have the _resources_ to do so. We have seen add-ons that eat CPU time in a way that we consider unacceptably inefficient. But if the add-on maker doesn’t have the internal capability to write faster code, that’s out of our hands; the plugin system lets people code _anything_ they want, fast or slow.

      If a developer has hit a situation where he or she thinks the add-on can’t go faster because of an internal X-PLane limitation, we like to hear about it. For example, the new object drawing APIs are not as fast as internal code paths and we’ve heard from developers saying they want more capacity there. That’s fair and that’s a good feature request that we can make happen (causing the add-ons to “just work faster”).

      But from what I’ve seen, most of the ‘heavy’ add-on aircraft are running a pile of per-frame code that slows the sim down.

      A simple test: disable all of the plugins running in your plane. How much faster does it get.

      (BUT: you have to be careful – if disabling the plugin changes HOW the airplane draws, which is quite common for third party add-ons, then the test is not quite valid.)

  12. Is this all what makes the moon flicker now in 11.10b1-5 when I’m showing 48 fps? 🙂

  13. I don’t get the point here…I was running 30fps steady in XP11.05 and now I’m gone at 10/15 with visible stutters. It’s not an FPS indicator fault. The sim is painfully slow even at the lower settings. Am I the only one experiencing this?

    2. You are not alone! I notice this too. I set everything to low on my iMac 27k late 2015 2G graphic card. and it was smooth on 11.05. but no it’s slower and has visible shutters. especially in large airports like KSFO. even if number of objects is set to low.

    3. I usually delete preferences if this happens, especially after a new version is downloaded (in X-Plane 11\Output\Preferences).
      Sometimes the preferences get messed up, after deleting them they get restored and you restart clean.

  14. So what is happening when the number of flight models per frame is increased? Smaller time step between each flight model?

    1. X-Plane sub-divides each physics frame for a sub-section of the flight model where some calculus integration happens – this part can be divided into more than two pieces.

        1. No.

          Someday we may allow multiple GPUs to drive multiple separate displays (with no more than one GPU per display), but we absolutely do NOT support even that config now, and we cannot sanely support it until we make the rendering engine _completely_ multi-core friendly.

          Even in the future when we have a completely multi-core engine and _if_ we then support multiple monitors each with its own GPU, we’re not going to do two GPUs on a single monitor…it’s not worth the ridiculous amounts of overhead, management code, and developer time to make two GPUs share a screen…if you have one monitor, get one big GPU and not two small ones. I have not seen cases where a user has a maxed out GPU (e.g. a Titan) and is bottlenecked on GPU compute power (the only thing this case would possibly solve).

          SLI is a solution looking for a problem…X-Plane’s rendering is simply not that problem.

          (Carlos – sorry for the rant here — I just want to be crystal clear because we get a lot of users asking about this and we don’t want to see someone go buy dual GF-1080s and be shocked that it isn’t awesome when one would have been sufficient.)

          1. Ben Supnik, i own a GTX 1080 sc and do not spend much of 30 fps, using X-Enviro and Reshade. Using the Mega São Paulo scenario sometimes falls to 15 20 fps. I’ll wait for Vulkan. lol

  15. Hi Ben,
    Thanks for the knowledge, I have a small question. For example, if you are below 20 FPS for 10 seconds. Does it mean the time in the sim will be exact 10 seconds slower than the time in real world? Please explain this, thank you very much! 🙂
    Cheers

    1. It depends on the fps. If you run at 15 fps for 1 minute, then 45 seconds of sim time will pass in 1 minute of real time. As you go below 20, the ratio of fps / 20 is the percent of real time (making you slower) that you fly.

  16. In 99.99% of the user leads greed and stupidity! Return chaff,flare,parachute-flares.
    Stop complicating the simulator,
    focus on eliminating errors and optimizing.
    All the best. I almost forgot the trimmer in the default take-off position it seems to me it’s not right…

  17. Wow, I am quite surprised and sad at the same time about the internal arcitecture revelation that physics and graphics are coupled together. What I understand is that physics depends on graphics? If so then thats quite a thing that my brain just cannot comprehend. And apparently you do defend that design choice?

    I would assume that you would have totally independent physics engine that only depends on user input. Pretty much a headless X-Plane that just endlessly calculates the flight. Based on that headless workhorse, you could make snapshots that would be delivered to independent graphics engine which then draws that physics snapshot at its own pace. Even 2 frames per minute if it so chooses. However that would not bother physics which is running independently on its own corner listening nothing but users input.

    So I am quite disappointed that X-Plane does not have that headless engine where graphics would just ask its state every once in a while for rendering. Also as this decision has been made and you are refusing to reconsider, then indeed only tiny optimizations here and there can be done to ensure that you will fit both physics and graphics “steps” within reasonable time frame that users find acceptable.

    1. Hi,

      The physics do not depend on the graphics. However, the graphics depend on the physics in that arbitrary amounts of visualization code look at the results of the flight model, which is a very wide pile of data.

      You can view X-Plane in ‘headless’ mode quite easily – set your one and only monitor to “2-d panel” rendering in a plane that has no panel or IOS and you are quite close to headless.

      Anyway, ignoring this entire red herring that somehow the output of the graphics engine is an input to the physics engine, there are two separate design ideas that need to be evaluated separately, because they are really different:

      1. The physics and graphics engine are independent, but run _synchronously_ (that is, they take turns) – you can play games with the ratio of turns.
      2. The physics and graphics engine are independent and run _asynchronously_ (that is, they may or may not be running at the same time and there is no guarantee that a frame ticking by in one has anything to do with the other).

      My point from the post is that idea two (async physics and graphics) is expensive – since it’s truly asynchronous, some synchronization mechanism is needed, and here we have only four bad choices:
      1. Put a lock on the flight model. I can elaborate on why this is a terrible idea if that’s not obvious to people.
      2. Transfer finalized output from the physics engine to the graphics engine as we have it. Now you will sometimes get a new frame to draw from physics every graphics frame, and sometimes not, depending on the exact timing…e.g. if physics is running at 30 fps and graphics at 25 fps, the amount of sim time passing each time we render is going to be inconsistent. So this sucks.
      3. Transfer finalized output from the physics engine with a full frame of buffering. Now we can interpolate between frames so motion is even, but we picked up a physics frame of latency. Mmmmmaybe this isn’t so bad if the physics is running really, really, really fast.
      4. Transfer finalized output from the physics engine with no buffering and extrapolate (a la what you do for a networked machine). Low latency, even output, but … sometimes the plane is in the wrong place.

      My point here is, there’s a real cost here … this cure is painful and you can get the same benefit by simply mucking with the ratio of physics to graphics frames. (If the problem was that one of the segments, physics or graphics, didn’t use all cores, the solution would be to find more internal parallelism in that segment – each one CAN be made parallel.)

      But this is all academic because:
      1. We do not have a design goal of running the graphics engine at < 20 fps, so this is all moot and 2. An async design would break pretty much all plugins, which we don't want to do.

      1. “Mmmmmaybe this isn’t so bad if the physics is running really, really, really fast.”

        Disclaimer 🙂 I don’t see a need for a change in all this !
        But : I am very impressed by how much graphics computations can be achieved 30 or 60 times per second, instead naively I would have expected the flight model to be able to run at (a useless) 1K+ fps and therefore just curious. Is collision detection the (only) bottleneck there ?

      2. Just a comment/question on the “We do not have a design goal of running the graphics engine at < 20 fps" idea.

        I think the goal when people are asking about questions about doing things in parallel or asynchronous (often conflating them) is to, as much as possible, get out of the way of the graphics card so that it can shove something to the screen at 3o+ FPS, because we partially… and sometimes poorly, get what you are trying to tell us about how the engine works.

        What you are hearing is something along the lines of "I think 15 fps is great, but don't want time to be scaled"

        I think the confusion is coming from the fact that unless you have lots and lots of flight models per frame, or lots of lots of planes, and unless you have reflections turned up all the way or are running 4K… neither the flight model or the gpu are particularly breaking a sweat.

        Rather, shoving geometry from the cpu to the card is the thing that has to happen 20 times a second or things get ugly.

        If you can only shove geometry 15 times a second, it'd be silly for the gpu to draw the same geometry in the same place repeatedly. It'd also be silly to calculate the flight model ahead of the input, or when the plane is essentially not moving (because the geometry hasn't been shoved yet..)

        So this comes back to being CPU/bus limited… and that either gets fixed by vulcan/metal (maybe, by reducing the number of draw calls or speeding them up or both) or by buying a machine with that can get through the geometry loop 2x as fast, or both (definitely).

        (context, i don't have the numbers on me at the moment but my recent experience with x-plane on a Mac Pro 2010 with a GT1060 is that i can jiggle the quality sliders around, i can add and remove planes, but there are only 2 things that matter, and thats the resolution i run at, and how much geometry i shove through the system bus/opengl. Pretty consistently the CPU draw time is 2x the GPU draw time, which is what you'd expect if you take a 7 year old 2.4 ghz processor and a <1 year old graphics card and try to have it draw tons of geometry.

        If i fly up to 50,000 feet and fly over kansas, it can do 30+ fps no problem.)

        So its a combination of "we don't design for <20fps, because anything we do to fix 20fps” and “we aren’t designing to make everything asynchronous right now because it being synchronous is how we get high fps on sufficiently powerful hardware.” (because if the flight model was at 60, the gpu at 50 and the geometry loop at 35, you’d have crazy stuttering and tearing and everything would look and behave crazy.)

        Is that kinda it?

        1. it seems the comment engine ate some of my text in the last paragraph… part of that should read: “we don’t design for less than 20fps because anything we do to fix it should result in more than 20fps”

          Sorry!

        2. Right. We don’t want to pay the tax to go async (development cost, debugging, overhead when running) to make 15 fps work better, we want to go faster than 15 fps.

          The viable thing to do that we are not pursuing is to have a higher ratio of physics to graphics so that the physics are stable at extremely low fps. We don’t want to take X-Plane in that directional, but it is possible. (My view is IF we wanted to go that way, a synchronous implementation would be the clear winner.)

  18. The frame rate is one thing.Another important things is smooth and stable.Most players have stutter and pause even at a high frame rate.And most of the stutter and pause happens in take off and landing.It is not about plugins.No plugins and default plane happens too.If we have stutter in take off or landing,it is the worst thing in simulator.So please pay more attention to the stutter and pause.Thank you.

  19. Are you working on to correct the tendency of C172 and, I guess, others prop aircraft to pull right? I have already sent a bug report about 10 days ago.

  20. I am so glad that you’re focusing on framerate. In VR one needs to be above 45 at all times, never to dip under.

  21. Actually when you have low FPS, you should pray to the waether good for less clouds (or fog) 😉 I don’t have a “top five” graphics card, so semi-transparent clouds seem to hit the frame rate most (clear skies and fully opaque clouds seem good).
    The only X-Plane version ever I had more than 40 FPS was X-Plane 4; there I had 85 FPS 😎
    On independent computing and rendering: Basisically(!) it would be as simple as to let the graphics tasks wait on a semaphore the compute task signals when it has done a new cycle. If the graphics task could work on a copy of the data, everything would be fine, but obviously the compute task(s) cannot continue until the graphics task(s) have finished (reading the data that might be modified next). So if the compute task has to wait for the graphics task to finish, the graphics task would basically set the speed of the computation!
    If you could do a kind of double-buffering, where there are two sets of computational output, the graphics task could work on one set of data, while the computation task continues to use (and update) the other set of data until the graphics task signals that it doesn’t need the other data any more. Then the compute task would signal the graphics task to use the other set of data for display, while the compute task updates the set of data the grapics taks had blocked before. Basically that means the compute task might update the data multiple times before the graphics task accesses the latest data (and is busy displaying som old data).

    1. I love any post that discusses parallel computing and starts with “It would be as simple as…” 🙂 🙂 🙂 🙂

      See my other post for the problem with double-buffering, latency, and display smoothness. These problems are solvable but it’s not something we want to solve.

  22. thanks much for taking off that earlier warning and allowing a “dont show me again”. I wish that feature was also tied to missing scenery warnings

    1. You actually can disable the missing scenery warning… the pref is just buried in Settings > General (“Warn about missing scenery” checkbox), rather than being “on” the popup. It really should be moved to the popup, though!

    1. How do you not find the reflection of the glass awesome? I love seeing a realistic windscreen reflect sunlight as I turn my aircraft in the skies!

  25. XPD-8441 Can’t turn off birds and deer
    You want to tell me we can’t turn OFF birds and deer anymore?????????
    Why???
    I don’t like this, I hate this feature, I want to disable this!!!!!!!!!!

    1. The irony of the birds and deer is… they’ve not been disableable since maybe as far back as 10.51. (The pref that controls them was inadvertently broken, so they’ve always been on since at least 11.02, maybe 11.00.)

      The only thing that’s changed in 11.10 is: you can now see them in the map, so you know they’re around!

      FWIW, we do intend to replace the art control that allows bird haters to remove them via manually editing their prefs. More importantly, we’ve reworked where they appear, so that you’re much less likely to encounter them organically when they’re on.

      1. Why the need to force feed a feature that really has no bearing on aircraft simulation? If people don’t want them, and you close the door on their ability to use a work around, don’t you realize that only alienates users? Yes, birds exist in real life, and they are admittedly a hazard. However, like failures, the user deserves to be able to control them, or 100% prevent them if they see fit.

      2. One other point that I forgot to mention – while many users have a *preference* to disable birds and deer, there are users that deploy X-Plane for the purposes of training, and *need* the ability to disable them.

        The unexpected presence of birds or deer can easily disrupt a training session, and waste time. I’ve worked extensively with one client already that is working to develop X-Plane based VR training, and I’m in the early stages of development planning with a second. Neither individual would appreciate having their endeavors interrupted by ephemeral features that can easily and currently be disabled – we’re not asking for *new* code. Instead of deleting the art control, make it an override dataref, at least. That would be reasonable, would it not?

          1. dont mind them too much, just that they seems to break you plane even when you are sitting still and there are too many. Maybe need random amounts like 1, 5, or 20

          2. I saw that, Tyler. That you repeat it suggests that I misread your intent. Clearly I thought LR would simply be removing it and users would have no recourse. Thanks for the clarification, and sorry for heaping on a bit. 😉

      3. Tyler, is there any chance the option to add/remove birds/deer will make it’s way into the failures as an option on the drop down menus or maybe a check box in the general settings?

        1. Failures, yes: even if you’ve manually modified your prefs to disable birds & deer, if you deliberately ask for them as a failure, you’ll get them back.

          As a checkbox: no, for three reasons.

          1) We see the birds as part of the environment in general, like trees, mountains, lakes, etc. To the extent that they’re causing people problems (e.g., pre-11.10b5, they showed up way too close to your plane, way too often), we should fix the underlying problem… not offer to disable them. Now that the system “just works,” we don’t think it’s going to cause problems.

          2) As an overarching design goal, we’re trying to be extremely selective about what gets a checkbox in the settings, because it leads to death by a thousand cuts. No individual checkbox makes the product much harder to use, but it’s easy to get back to the state of X-Plane 10 preferences where “everything’s a checkbox!!!!” and nobody can find anything, or knows what things actually do (even us!). Instead, our philosophy has been: we UI for critical options where we can’t make good decisions a priori, and apply sane defaults for everything else, with some support for hackers to tweak things if they’re really interested. (If you’d like 2,000 words explaining this philosophy, Joel Spolsky nailed it on his blog.)

          Another option that we considered and decided against was the possibility of having the birds & deer only enabled when you have the global MTBF on. This makes sense to people with Stockholm Syndrome who were power users of X-Plane 10 and earlier, but to the rest of the world, it’s totally baffling—hence the “animals as scenery” model.

          1. Thanks for the response, I was curious as to what the future design might be. Ultimately if it’s a hackable prefs option you probably wouldn’t hear any grumbling in the forums. For me sometimes I want to record my aerobatics. So, I just want to insure it doesn’t end in a bird tragedy that borks the replay (with missing flight surfaces and brown smoke trails) which I use to evaluate what went right or wrong in my flight. But it sounds like it’s going to be a non-issue by design which is great.

            Excellent article by Joel Spolsky. I learned the hard way working with customers and their design ideas via web design (not knowing when to say NO/BAD IDEA) as I explain the how’s and whys of designing something that’s user friendly for “everyone” and “now all the different devices” “yep, I’m old” when the customers focus on how they would like something designed and it’s only based on “how they use the site” and how it looks on the screen with “their preferences.” Then you try to explain why you should not design something in a particular way because it doesn’t translate to everyone or it’s just kookoo for cocoa puffs, so I fire the customer, LOL. I’ve had customers who want designs that are so clean looking no one has a clue how to find anything or designs that are so choice and option oriented to please everyone you get completely lost and frustrated. Finding the balance is a challenge. It’s nice to see you open your doors to our user/customer input insanity.

  26. Looks like the too-small icon generation size issue is gone, but somehow there is some info based on the old algorithm that informs the sim of a preferred initial viewpoint distance from the aircraft when commanding an external view from an internal view — seems as far as the old icon basis.

  27. The “oh, I’ve learned something, I’ll turn down my rendering settings.” has one big problem, which is: “turn down to what?”

    The open nature of X-Plane as a platform means that the variation in “stuff” that it needs to render can vary dramatically from area to area. Add various planes and weather conditions to that and you can probably find a reason to put everything on “minimum” just to get the extremes to be bearable. I personally dislike doing that when I know that I’m just fine 90% of the time.

    There are some plugins that make a decent attempt at dynamically reducing settings when the framerate drops below a given minimum. To me this seems like a much more reasonable solution that to throw an arbitrary “reduce settings” dialogue towards the user that only bears relevance to the random situation they just found themselves in. X-Plane should be able to make pretty well informed decisions about what features could have temporarily reduced settings in order to let the flight continue relatively smoothly.

  28. Stall behavior

    I just wonder whether it is a bug or just a limit of the used physics behind X-Plane.

    Normally, if you fly near a stall, with slow speed and a high angle of attack, it is wrong to use heavy aileron deflections. I’ve learned, if one wing goes down, use the rudder to level it again.

    Using the aileron could lead to a stall at the wing the aileron moves down.
    In that case the airplane will roll upside down.
    (Could look like this: https://www.youtube.com/watch?v=YZIzEtHzbNU)

    With X-Plane I’m not able to trigger that kind of accident.
    The plane will lose hight, that’s all.
    For the record, I did my tests with the Carenado B200.

    Do you think I should file a a bug?

      1. Ben,
        I tried the C90B and the behavior is the same.
        I supect it is the result of how the airflow is simulated/calculated/…

        Maybe it is a intended limit of the airflow model, maybe it should work but is broken.

    3. Carenado flight models are fairly primitive, relative to what X-plane is capable of. Not really a good test of X-plane itself.
      The new airfoil format in 11.10 should allow greater realism of wing behaviour across a very wide range of conditions (I am possibly the only person besides Austin who excited about this!). Of course, there ARE limits, modelling stall behaviour at 30fps with current desktop computing technology cannot be perfect, but it actually pretty darn good considering.

      From my own real-world testing, behaviour with the use of aileron at the ‘stall’ depends strongly on aircraft type – some will mush around just fine, others will rapidly point you at the centre of the earth. Or sky / earth / sky / earth…. 🙂 Others, if actually FULLY stalled will have almost no response to aileron input at all.

      TLDR; Some flight models just are not that precisely made, and not all aircraft behave in the way textbooks generalize.

      1. Don’t forget, the X-plane C90B acts very exactly wrong as the Carenado B200 in my test.
        My understanding is, in the aircraft file you have to describe the geometry of the plane, wing type, surface, center of gravity etc., the flight model – how the plane reacts – is part of the physics that X-plane is using, am I wrong?

        For me it looks like X-plane doesn’t handle a stall condition on one wing only (left or right) in the right way.

        And sure, you are not the only one who is excited about the aerodynamic behavior of X-plane, count me in.

        Beta testing is there for looking for flaws and I trying to do my best 🙂

  29. Just moved to 11.10 b5 and was pleasantly surprised to see that I can crank up time acceleration all the way to 16x.. So what is the catch here and why was it not possible earlier..

    1. Doh. This was a casualty me reorganizing how the “slow sim” notification works. I’ve restored the notification that we aren’t able to run at your requested “time speed” for b6—this will be listed as XPD-8473 in the release notes.

  30. Dear Ben,

    Re: FM and Graphics asynchronicity – there are two fundamental concepts underlying your post which I see all the time as a consultant when I talk to clients re: technical debt. Its painful to fix properly and its going to take cycles away from “productive” work (point 1) and we may not see any appreciable benefits immediately in fact, things will get worse ( point 2 ). Typically both are true and false to varying degrees. I’m sure ( from reading between the lines) that these topics have been heatedly debated at LR internally :-). A scalable architecture could run external views ( world geometry , rendering, fog, particle effects) as one component with plane location and user position as a reasonably simply interpolated input from the FM, internal views ( panels, gauges) as a second component ( requires more input from the FM ) , and the FM itself ( forced and control inputs ) as a third component. This is a radical architecture overhaul, but IMHO, putting it as a moonshot target, and working towards it with every release should help improve the core product. Thanks for all you guys do!

    1. Hi,

      Wait – we have things that are technical debt. This is not one of them.

      We have lots of ways to add parallelism to the app that we are trying to pursue. This is just not one of them.

      Async FM isn’t technical debt, it’s a solution looking for a problem.

      1. Looks like the synching of the FM is a hot topic… 🙂

        I think an async FM could resolve several problems:

        1) I presume XP, even with Vulkan, will always have minimum requirements. Will such a pc keep >20fps with max settings, heavy add-ons, and 4K (or upcoming 8K) screen(s)?

        2) An async FM could provide a fixed time acceleration (I presume), while as of now the max time accel is limited to (FPS/20)X;

        3) A locked FM means any aircraft will be forced to run at the same fixed FM frequency (and the acf designer will be soon aware if its aircraft doesn’t work). It will not be necessary for users to dabble with the obscure “flight models per frame” setting. Of course the fixed FM time step should be low enough to allow the modeling of light or very fast aircrafts.

        Now, that being said, you previously mentioned that a fixed FM is not good. Why is that? AFAIK, most flight sims (including commercial ones) use a fixed FM, although I presume with a quite low time step. Why do you think a locked FM is a bad thing?

        1. Hi Marco,

          1 and 2 can be solved by simply running the TOTAL FM at a higher ratio to the physics than the 1:1 we do now – async solves a problem but it’s not the only solution or anywhere close to the cheapest one. (Right now the calculus can be run at a higher rate than the graphics but the systems sim does not run stepped up.)

          Re 3, I don’t think I’ve ever said that a “fixed FM is not good” – I definitely think a flight model that runs at a fixed time step IS good. It’s just that I think that:
          – A fixed time step is nice.
          – Running the graphics and physics with their frame markers truly async is a mess.
          – The mess of async outweighs the benefits of the fixed time step.

          We run internally in non-real-time with a fixed time step for testing purposes, but it’s not something I’ve heard any clamoring for from users.

          I do get the infrequent request to run at extremely high fps or faster than real time with graphics disabled – this is possible now by putting the sim into 2-d panel only mode – you can get to about 200-300 fps on a decent machine. We may have support for doing this in non-real-time (e.g. simulating 1000 fps at 1/5th speed by running 200 fps with no graphics) in 11.10 via datarefs. But this is a very specialized use case.

  31. A quick question about scenery updates in 11.10

    I have made European overlays for Ortho4XP from the default global scenery in 11.05. Has anything changed in 11.10 in this regard other than art assets…in other words do i need to remake my overlays?

    1. I did the same thing, and yes, if you want to see the new art assets, you will have to redo the overlays in yOrtho4XP_Overlays.

    1. Hi Daniela,

      I think it’s vice versa: the new runtime can read banks saved with the old studio app, but the old run-time can’t read banks written by the new studio app because the bank format is newer (and has stuff unknown to the old runtime). I am _not_ sure about us upgrading – our license has limits on our ability to take up-stream changes, and I think some changes may not be backward compatible. I’ll check with Chris on the fine print.

      1. Yes that’s what I meant 😛
        Thanks for looking into this; if the runtime is backwards compatible and your license permits it would be great to have these latest features available.

  33. I think the new warning is a lot better. I have seen it a lot though. Performance with X-Plane 11.05 and 11.10b5 under High Sierra has been pretty crappy so far. I’m getting about half the frame rate that I used to get with Sierra. iMac 27″ 2017, i7, Radeon Pro 580. I have a Sierra partition that I boot from just to run X-Plane

  34. Ben, it’s possible that the runway lights are reflected in the pilot internal view windows.?

  36. Ben,

    As we are now a few weeks into 11.1o beta, do you think you could give us an updated roadmap on what to expect. What is the plan for the rest of the 11.10 beta period, i.e. just additional bug fixes, or potentially some additional performance improvements? Understand native VR comes after 11.10 final. Anxious to hear some more details, i.e. which HMD’s (Rift, Vive, new Microsoft MR’s?) will be supported and whether you will be able to import external windows.

  37. Ben the silence on when we will see a fix for the VERY VERY borken tail drager ground handling is infuriating. THIS NEEDS TO BE A TOP PRIORY I have filed MANY bug reports about it and heard NOTHING back

    1. @Elios .. Really? LR are nice enough with the community to be open to suggestion, share details, spend time writing nice blog entries and you write this?

      Of course you know what ‘NEEDS TO BE A TOP PRIORITY’ because you’re taking the business decisions on how to run their company?

      If you want to help, I suggest explain the issue with a good bug report, data, facts, why that’s important for, etc (which I’m sure you already did) and that’s it. I’m sure they are capable enough on prioritising the bugs according to the way they want to run the business.

      And, on a personal note, seeing comments like this one in this otherwise nice blog is what seems infuriating to me.

  38. Ben,

    as a follow up to James elder’s question above, I have a 2017 iMac and wanted to see if you can share how/ if/when VR will work on such a machine?

    —

    also, in your opinion, I am at 32GB ram now, my activity monitor usually hovers around 12GB or so when using x-plane 11 & multiple other apps. Despite the full 32GB not being used, my system can get delayed a bit. When I went from 8 to 16, 16 to 32 I noticed system and x-plane improvements. – would going to 64GB do anything? -> fps , load times of ortho scenery areas, menu loading

    thanks!

    1. VR won’t work on your machine at all when we release it because the first VR release that we’re trying to finish up now is Windows only.

      After we finish the port to Metal/Vulkan, VR should be available on Mac. I can’t comment on how the 2017 iMac will work because we’ve never run VR on it.

      I don’t think more RAM will help past 32 GB…it would just be even more unused RAM. Maybe you’d see some load time improvement _if_ you have a non-SSD, but maybe not.

      1. Thanks for all that Ben, I will save my cash back rewards for something else, I figured as much for the ram but wanted opinions for more knowledgable people.

      2. One more thing Ben- where is the best place to put a suggestion?

        ” can you add a drop down on the aircraft selection page that shows weight and fuel etc, that allows you to clasify the plane? vs going to the plane maker

  39. A bug has been filed regarding massive excess messaging in the log.txt with 11.10b6. Posted here as a PSA. 🙂 Kinda hard to track other plugin issues through the blizzard.

  40. Hello Ben
    X-Plane 11.10 betas are very well now. Some small bugs are still exists, but there not really big problems.
    The big problem since the first X-Plane 11 release is the DSF`s scenery reload during the flights. Every time when X-Plane 11 is reloading new DSF`s the simulator is coming with massive stutters. And this is killing the whole fun on this great simulator. And also if you have some couple addon airports installed in this DSF area, the pauses and stutters are extrem. Maby the X-plane Team find an solution to reload the addon airport scenerys in an shorter circle (reducing the massive load), and also the DFS`s in a smoother variant.

    1. You don’t need to refile this bug. If we didn’t announce in the release notes that it’s fixed, or if you re-filed it once after it was announced fix (the 11.0x fix was a very PARTIAL fix) you’re not actually doing anything useful by repeating yourself…you’re just delaying Jennifer from looking at new bug reports by repetition.

      1. Sorry and thanks.

        Has the team confirmed the bug at least? I’m just surprised that something like this made it so far.

        Even yesterday flying to Manchester, my buddies were all commenting on the poor visibility they were having of about 5 miles… but I could see everything. I went and checked the weather conditions, and exactly like they said, visibility was 5 miles… in theory!

        Cheers.

Comments are closed.