We’re reaching the end-game with X-Plane 11.0 public betas. Right now I am working to try to solve three problems at once:

  1. Users of the beta really want to see rendering issues solved ASAP. Besides the constant chorus of “you know your sky looks like hell” in the comments section, the cloud code has serious performance tuning problems that I have been working on. We definitely want faster clouds in the next beta so it is a useful beta.
  2. We are trying to get the flight model locked down ASAP. We’ve received a number of really good bug reports in the last week and fixed a bunch of compatibility issues; the sooner we get those fixes out, the sooner authors can confirm their planes work.
  3. There are some issues that really need to be resolved in 11.0 because fixing them mid-version (where backward compatibility requirements are much stricter) is a lot harder.

You can see where this is going – those things are totally at odds with each other. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. If we don’t fix cloud perf, the build isn’t useful. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy.

I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. I also made some progress on cloud tuning last night; I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance.

(Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!)

I’m hoping to have beta 16 out Monday or Tuesday.

One Last Change

The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales.

X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.

The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would.

The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. if the knob is being driven by a custom manipulator or command or some internal plugin path.

This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent.

I have code that I am planning to put into beta 16 that puts the behavior back the way X-Plane 9 and earlier was: the value of these datarefs will be rounded to a grid only when Plane is done twiddling them. If you write to them with a plugin or manipulator, you’ll get exactly what you ask for – at least until the user touches a built-in panel instrument or command or some other pure X-Plane path.

This change is a little bit scary – there may be plugins or add-ons intentionally writing not-rounded values and counting on X-Plane to round them. This is a change that we can put in one beta and remove in the very next one if it turns out to cause too much chaos.**

But I am certainly hoping we can make the change – having X-Plane only round when needed makes a much better and more convenient interface for add-ons – add-on authors can get exactly what they want without having to wrestle with an octopus.

 

* Not impossible – just very difficult. To work around the problem, you have to inject your own values in a hook after X-Plane and manually track what the value should have been so that you don’t get fooled by X-Plane constantly snapping the value. There are a number of “unwritable” datarefs where you can write them by just shouting louder than X-Plane, but I strongly recommend against using this to make your add-on work. If you need to do this, contact us about what dataref you are fighting about – there might be a better way.

** This is going to be one of those cases where if one or two add-ons is broken by the change, we’ll declare it as “this is how X-Plane 11.0 is”, but if 100 add-ons are broken, we’ll put it back and I’ll have to go drown my sorrows. See also the usual joke about owing the bank $100,000,000.00 and all that.

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.

58 comments on “Trying To Solve Three Things At Once

  1. Projects have up and downs…important thing is to fight against the downs. You have done really good work so far. It’s only fine tuning. End of the year the job is done…no one remember the hard beta phase.
    I hope that in finall all graphics will done by the GPU-VRAM.
    There i see an major problem.
    At the moment it’s a cpu thing. That’s a problem for many users.
    Done by GPU and VRAM… performance will rise rapidly.

    Or is it more complex ?

    Cheers

  2. Hi Ben,

    I’m using X-Plane 11 in “windowed mode”, but everytime I start X-Plane 11 I’m back to “full screen mode”.
    Doesn’t the window setting get saved, like in X-Plane 10?
    Thanks,
    Marcus

  3. Hi Ben,
    is “ground lights shining through clouds aka clouds not blocking ground lights” part of the rendering issues you are trying to solve for 11.0 or is it too complicated?

    Anyway, good luck with 11.0
    Flo

    1. It’s definitely on my list to look at – I can’t promise it’ll be fixed because I don’t know what’s wrong. I definitely want it to be no worse than v10, and I’m told it might be right now.

    2. Hey, i know that Ben is working on that. I think its very important to fix it, because at this state is very unreal. But good luck ben…..

  4. Hey Ben,

    thank’s for informing us about the progress, really looking forward to the final release of XP11. I might have missed that in earlier Blog-Posts but are you planning to get the “live-update while sliding” feature of the Replay working again? It is quite annoying at the moment, only updating the view when you release the slider. The old replay slider felt a lot more natural to me.

    Best regards,

    Benjamin

    1. Here’s what’s gong on: we have a new FX system which is partly in place on desktop, but mostly not used for default art-work. (On mobile it is the only source of effects.) We’ll use it more heavily in the next few updates, but the infrastructure is there.

      In X-Plane 10, Austin’s old effects system doesn’t do replay. You know this if you ever replay a flight and find yourself flying along the smoke trail of your own flight path.

      The new system does replay effects – we needed this to make replay on mobile look good if you crash your plane. But the effects don’t play backward, because the effects record the _births_ of particles but not their _deaths_.

      To get around this, the new particle system jumps backward to several seconds before the time you want and plays forward to let the particle effects evolve to where they need to be. The cost of this ‘jump back and go forward’ is what is making things sluggish.

      I expect our work-around will be to disable effects while the slider is held down for fast “scrubbing”.

      1. a cool thing would be to replay and jump in – for instance because something went wrong during a long flight

        best regards

        1. That is a long term goal of our work on the replay system: complete “resume-ability”. E.g. all new code and changes for replay have to make this more doable and not less.

  5. People tend to ask “why this thing is still not fixed?” or “why anybody listen to my complains?”. But I have the real question this time:

    Ben, do you ever sleep?

    Jokes aside, this snapping behavior is the same thing that happens on the fuel, amps and ADF instruments on the C172? Or is related to autopilot only?

    1. The only snapped variables are: autopilot speed, autopilot vertical climb rate, autopilot altitude, radio altimeter height (pilot and copilot), altimeter barometric pressure (pilot and copilot).

      I’m not sure what sleep is – probably best you file a bug.

      1. These things always needed a timed manipulator and rounding, all easily solved by plugin. You need a fast manip and a slower manip depending on the lumpiness or whether you use an accelerator that increases lumpiness after 10 cycles. Typical slow manip would be for cabin altitude and baro pressure; typical fast manip would be for autopilot altitude or heading, accelerating after a number of cycles.

        What is keeping me from using XP11 (no point in using 10 any more) is cockpit lighting. What icons and text SASL drew on screen are now dim or jaggy-edged in 11 vs 10. Panel and generic spills exquisitely tuned to light up cockpit surfaces hardly light in 11, and _LIT labels don’t light. So many things changed that I had to throw the towel into the ring. I can’t even figure out what is or isn’t a bug. Meanwhile, the cryptic lights.txt seems to be identical with 10’s…

  6. Ben;
    Thank you for your insights. I am software developer too and struggle with the same what needs to get done first quite often. In all dull respect, I would fix things in the reverse order, 3, 2 and latest 1.
    My opinion is that 3) should have the highest priority. It may not be of high priority for the x-plane community, but pays off long run. Issues in 2 would be next as other developers in the market need your fixes. And last, rendering performance, lighting, clouds and glare issues can be fixed later as I am sure you know how to address this. As long as you can provide a roadmap to your customers, it should be fine.
    I run PB15 with a 4K resolution on a mediocre 1070 GPU and an old 5820 CPU with 30 – 45 fps event in the busiest areas, all sliders at max. And yes, I wonder about the skies, but know that it is going to be fixed sometimes, no worries to me.
    Just my humble opinion from a software developer’s perspective with respect towards your skills.
    Best regards from Germany
    Christian

    1. If you are a software developer, then grading things by “patchability” and “impact to the code base” make sense. We are going to have to defer some v11 bugs to 11.01 or 11.05, and I’ve pushed hard to make sure that plugin system compatibility and aircraft SDK bugs are not on that plate.

      With that in mind, EVERYONE notices that the sky has banding – I probably get asked about it twice a day. So just because it has zero compatibility impact doesn’t mean it doesn’t affect us.

      1. I might have found a bug in the SDK function that stores situations via XPLM call. But I’m calling that function right when the sim is closing, and it crashes. I’m guessing that maybe the sim is now trying to store a situation too upon close, and there’s a logjam for the functionality. What do you think? This particular plugin works fine in X-Plane 10. It’s pretty simple, if you’d like me to share the code.

  7. With 2 simple steps, or hacks, the clouds are a non issue and the performance of the last beta is the best so far for myself. I reframe from sharing because I know it is a work in progress but I am confident that the X-Plane team are finally taking a serious look at the most important aspect of a flight simulator, the environment in which we fly…not to mention the flight model, the navigation, the interface, which I still hate, the………..well, you know

  8. Since you mention the end-game for public betas… I have to ask: is it in the plans to make the Cirrus jet have RNAV capability? I LOVE that plane. It pains me to see the FMS buttons in the cockpit but not be able to use them. I would absolutely love to fly IFR with it.

  9. Performance is part of code stabiltiy.
    For me to fly the beta, it is not effective to test all the systems with 13FPS and stuttering sometimes 8-6 FPS.
    Other hand it get problems with real time flying. Timing. Effected by the FPS.
    And it happen that the flight model get complete freaky due to the code.
    Finally i need performance and stability.
    Hope for PB16.

  10. Kind of off topic, but with the beautiful new cloud drawing engine, have you given thought to perhaps releasing an API for more fine-grained weather in some future update to V11? At the moment, weather injectors cause really abrupt cloud redrawing and sudden changes. I’d love to be able to adjust weather state in a more gradual manner. 3rd party cloud rendering engines do it through a private implementation-internal channel, but it’d be awesome if we could have something like that available out of the box.
    Thanks!

    1. We have not. There isn’t really a good lower level set of primitives to expose. The input weather files are the best we have right now.

      1. Well consider this a kind request for such an interface. ATM the stock weather interface is extremely limited and it’s impossible to construct sophisticated weather injectors like AS2016 for X-Plane, short of completely replacing all the wonderful work you’ve done with the new cloud rendering engine. The lack of a good weather injector is one of the few remaining sticking points that gets brought up in discussion forums all the time (the other being the lack of support for seasonal textures).
        Thanks!

  11. Can we expect better performance from autogen, I have bad performance when I land at EGLL and EDDF default scenery with default 737, 10-15FPS less than anywhere else! Is this a bug?

  12. I see huge fps drops every time the sim loads new scenery tiles.
    In flight with autopilot this is a little stutter,
    but if this happens at the runway touchdown zone,
    then it is very annoying.
    I have this every time i try to land at LOWK RWY28.
    For repro test start @LOWK, rwy28, 10nm approach
    Exactly at runway it loads the next 3 tiles nw,w,sw.

    I hope the impact of scenery loading can be reduced or better shared
    with other cpu cores.

  13. For me xplane 11 is running very well but there is one thing that still annoys me. In xplane 10 the graphical options were a lot wider, the user was able to manipulate the quality of shadows, the rendering distance, the amount of each scenary object, etc and that, if you had a powerful system, could made the graphics look very complete. xplane 11 graphics are awesome but not being able to tune little things like the shadow quality in the cockpit for example, kills part of the realism for me. I know we are still in Beta but i hope you guys can add more graphical settings in the future.

    1. The problem with shadow quality isn’t “we took a setting away”. It’s me _screwing up_ the shadow volumes.
      The fix isn’t to give you some kind of internal control over the shadow layout – it’s for me to fix where the shadow volumes lie.

      There are tweaks that we took away that were at least sane to an experienced user (autogen distance vs density), but as I’ve blogged before, we expect the LOD system to change quite a bit, and the resulting system isn’t going to fit a 2-axis preferences system.

      1. Thanks for the info Ben!! Great to hear you guys are working to fix this issues. By the way, i manged the temporary fix the shadow quality problem by editing some lines of code in the dataref.

  14. We need more an adavance graphics option, what we have at the moment in terms of iptions is to vague in my opinion. Thanks

  15. It’s not the trick to turn down settings.

    Actually XPlane uses 400 MB VRam of my 1050TI.
    I got 4GB.
    And GPU is at 30%.
    CPU 50%
    And i get only 13FPS !!!

    So it’s big performance failure in the script of X-Plane.
    Hope it will be fixed in PB16 !

      1. I’m not sure how important the label on the rendering tech of cloud systems is. In the end:
        – Pretty much anything that responds to camera location is at least somewhat 3-d.
        – Anything that is on your computer monitor (without VR goggles or stereo-LCD like NVidia was promoting on gaming laptops) is distinctly 2-d.

        Particle systems are usually rendered via billboard, and billboards are one of multiple ways of rasterizing a theoretically 3-d thing onto a 2-d screen. And rasterizing 3-d volumetric data with with billboard clouds goes way back to both the Wang paper that was the foundation of MSFS’s clouds and the academic paper that Austin found that formed the foundation of X-plane 7’s. (I don’t recall the original paper Austin used, but it was the original “make a point cloud, sort to the camera, and rasterize it to capture self-shadow.” What we do now is quite a bit different in terms of lighting, but it’s still a 3-d point cloud approximation of a mathematical 3-d volume rasterized as 2-d billboards.)

        For every cloud system in this bucket, it’s like Penn-and-Teller – no one has made a ball disappear from reality, but there’s considerable art to slipping it into your coat pocket in a way no one can notice. Having fought like hell with our cloud system for years, I appreciate anyone who can make a volume->particle->billboard system look good.

        The “big” jump in cloud tech is for the systems that are using ray marching/volume tracing. This skips the particle and billboard step completely and directly attempts to trace the underlying volume on the GPU. It’s way more expensive in terms of compute resources, but it’s a better fit than particles for what the GPU is good at, and gets a bunch of other nice rendering properties too.

          1. Oh god, the day X-Plane has that, I won’t be able to get back to real life anymore 🙂

  16. Hi Ben!
    I’ve filed this bug, just decide to post it here. It seems there is a bug with atmo scattering in new shader model in XP11. This bug makes the whole scene in XP11 very yellowish *at afternoon* due to out_scattering. The snow caps of montains become dirty-yellow at noon. Something wrong with out_scatter_tint? Red tint become very strong and the lanscape become dirty-yellow. There is no such effect in XP10.
    Here is the picture of default scattering: //pixs.ru/showimage/X11default_1970300_25527318.jpg
    And here without out scattering: //pixs.ru/showimage/X11without_2977582_25527319.jpg
    Please check it if it possible. Huge thanks!

  17. XP11 with the new clouds is one awesome experience.
    For me, with the new clouds being performance optimized, and the jagged sky coloring issue resolved, XP11 is ready for release.
    Mileage varies form one to another, but I condsider everything else rather minor.

    Being an old beaten dog from using Microsofts Flight Simulator since 2000, I’ve learnt my
    lesson regarding hardware, and am running Xp11 off an overclocked i7-4770K@4.6Ghz with an
    also overclocked GTX1080. I really have to say I’ve never before experienced such fluid motion in a flightsim as it is now with XP11 (on pb15).
    Clouds have some hick ups on occasion and obviously the jagged sky is annoying, specially given the marvellous environmental lighting XP11 offers otherwise, so with these things
    resolved, I’ll be a sim dream for me.

  18. Ben,
    It is sometimes hard to figure out what is going on when people get low framerates, but this past weekend on one of the facabook X-Plane pages, someone was complaining about the low framerates and he had one of the latest nVidia graphics cards. Quite a rant! After some back and forth, it was determined that he had his HDMI plugged into the on-board graphics card and had to be given some instructions as to how to find the right one. This led to some of the others finding they had done the same thing. I appreciate your efforts, but sometimes you can be chasing your tail!
    John

    1. John, you should repost this on the xplane.org forums if not already done.
      I’ve read many posts from people with vastly superior rigs getting worse performance, and no-one seems to have any idea.
      This is almost comical and surely would both amuse and infuriate Ben and crew.

  19. Hi Ben,

    Any plans to improve the way street lights ‘pop’ into view? If extending the LOD is not feasible or too heavy on performance would it be possible for them to gradually fade in (similar to building autogen) so that it isn’t so distracting? Everything is really coming together so nicely in the XP11 environment but I fear this will be the one thing that will continue to adversely impact immersion, which is a shame as takes so much away from the fantastic night lighting.

    1. This has been talked about in previous dev blog comment sections. Ben is aware, Austin bugs him about it too.

  20. Love hearing about all the things taking place. X plane 11 is running great and looks awesome at my end……
    I filed a bug about a particular seaplane having a conflict with the water…per your suggestion Ben….Is there any word if that turned out to be some thing at xplane end and if a fix might be included in upcoming betas? I truelly love this sim. ..my yoke came today, and I am very hopeful to be able to fly my favorite seaplanes again! This sim is amazing and I am glad to have gotten to be a part of the beta program. Keep up the good work to the whole team!

  21. Hi Ben,
    I’m new to Xplane, proud owner of v10 and v11pb15, (coming from FSX)… good job!

    Anyway, today I tried the plane maker for the first time ever. I was just looking at different screens and tabs to see what it’s capable of, without changing anything. And then after closing the app, typical windows error dialog appeared: plane maker.exe has stopped working etc

    I saved the log file immediately and tried to reproduce this but I had no luck.

    Should I file a bug? I think you have other important things on your list now…

  22. I don’t want to change any datarefs, but what this man achieves on the inside and outside shadows with just changing datarefs is hard to understand. Can’t X-Plane have such good and crisp shadows by default?

  23. Hi,
    is it by design or are the titles of airports in default 737’s NAV display too small – unreadable?

    [IMG]//i65.tinypic.com/e6ruwx.jpg[/IMG]

  24. If I understand this behavior you were describing in the quoted text below, would it be possible for you to apply it to another instrument so behaves in a favorable way: the VOR indicator OBS knob. Currently in X plane 10.51, if you drag the OBS knob and let go near the desired radial, it can land between two radials as seen in the data output (i.e., 075.53, 167.2, etc). When using the scroll wheel support, it does a nice job of going one radial at a time. However it will always land on the in-between value that occurred when the drag manipulation last took place. This air can lead to one being off airway center aligned with tracking a long radio segment along an airway. True, it is likely we will still be within the tolerance of the width of the airway even if we are up to a degree off, but it’s always fun to be on course when we look at ourselves on the map after tracking carefully with the centered CDI.

    “X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.

    The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would”

  25. X-Plane is freezing for me (PB15) on an iMac when I use keyboard commands to alter the time of day (doing the same in the UI does not crash the sim). This seems to only apply when I do a rapid change (i.e. Shift-L)

    The freezing necessitates me manually having to restart my Mac by holding the power button. I can still hear aircraft sounds, but there is no visual movement and the entire system becomes unresponsive.

    Just wanted to check this is not a known bug?

Comments are closed.