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

Release notes detail the bug fixes here. We have another set of bug fixes that will go into beta 4 next week.

We’ve received a number of bug reports from plugin developers trying to use the new plugin APIs. We’ll have another beta next week to address the rest of the open issues, including the ability to (finally) use widget-based UI in VR.

Beta 3 fixes the MFD brightness going crazy in the G1000 C172, and fixes shadow casting on transparent-alpha-textured objects, but we still have an open bug with panel brightness in a Carenado aircraft that looks like a low level rendering bug. 11.20 has a lot of change to the rendering engine to support VR, performance and our migration to Vulkan and Metal, so authors: please be on the lookout for changes to how your models render compared to X-Plane 11.11.

If beta 3 isn’t found to be a smoldering wreckage of poorly thought out C++ over the next day, we’ll post a Steam version of the beta.

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.

54 comments on “X-Plane 11.20 Beta 3 Is Out”

  1. Thanks to all the team for this fast update ! Things are getting in order. I learned a small thing from reading the release notes. Does everyone contribute to writing the release notes and bug fixes or is it J.Roberts idiom ? After looking up all known SDK headers, kernel modules, standard and derived C++ libraries, finally it was simply wikipedia which taught me what “tchotchkes” are. I’ll adopt that one in my code comments !

    1. Jennifer writes the release notes but she pulls the bug base and source control logs, so parts might be copied from the engineers – it looks like XPD-9044 and XPD-9045 came right out of source control.

      Tchotchkes was a game of chicken I lost. Chris hates naming his C++ classes – he’s never satisfied that the name is just right. So when we had a C++ object for a “thing you can move around in VR space”, he asked me what to name it. I was totally annoyed – he should go name his own classes, right?? – so to troll him I told him to go call them tchotchkes.

      Chris called my bluff – he looked it up, figured out how to name it and now we have:

      vr_tchotchke
      vr_object_tchotchke
      vr_overlay_tchotchke
      vr_resizable_overlay_tchotchke
      vr_window_overlay_tchotchke
      vr_plugin_window_overlay_tchotchke
      vr_xpad_tchotchke
      vr_radial_menu_tchotchke
      vr_text_menu_tchotchke

      So…be careful what you wish for, I guess?

        2. Clean Code rules…….hahahahahahahahahahahahahaha…..*breathes*……hahahahahahahahahahahahahahah….*snorts*……hahahahahahahahaha.

          If we deleted code that violated those rules we’d be left with int main().

          1. Looks like we gotta delete that too, main() without argv is naughty in the new modern C++ the kids are always yammering on about.

            And…YES. We’re down to zero bugs.

          2. “And…YES. We’re down to zero bugs.” Do I sense a b4 coming soon?

          3. Normally yes, but since we’ve deleted every line of code in X-Plane that violates code complete, plus int main() for violating C++ rules about const, there’s nothing left to release.

          4. DOH! I was so hopeful that I completely missed the humor in your statement. Of course, zero code = zero bugs! LOL – should be the quickest download ever – just delete the X-Plane directory and you’re all set!

        3. I tend to agree. It’s all fun and giggles until a new member have to ramp up with the legacy code 😛

          1. I think naming classes properly is one of the hardest things in code – well not hardest but definitely not easy! I always spend way too much time pondering them, think I’ve got it right and go back and look in a few days and… ‘what was I thinking- these are terrible names!? ’

          3. Philipp, there are only 10 kinds of people in this world… those that get it and those that don’t!

      2. And I thought it was about Chukchi people. In french, it’s written “Tchouktche” 🙂
        Don’t fire Chris before extracting every distill-able drop of talent from his brain ! 😉
        Cheers,
        Pascal

  2. Is this still an issue with any VR users? It’s still showing up under “known bugs”

    XPD-8074 Cloud shadows are twitchy.

    I only ever experienced that when I was using FlyInside. Shadow flickering has been gone since your first VR beta.

  3. Any comment on the “linux performance issues” referred to in a post or two back? It hasn’t been showing up in the release notes. I’ve been seeing significant ram usage and poor fps for quite a few releases now but haven’t been able to isolate enough for a bug report.

    Speaking of release notes, that list of gateway airports is getting quite… long… My inner lazy is wondering what “Uncle Bob’s clean code manifest” would have to say about it being at the top of the release notes page. There are so many juicy bits on that page that certainly Bob’s advice would leave more than just !

    1. That was supposed to end as “just &lthtml&gt &lt/html&gt” but “int main()” works just as well…

    2. Re: linux perf, we’re looking at it now. If you haven’t filed a bug, please go file one and include system info so we can include you in our list of distros where we’ve seen this.

      Good point about Uncle Bob. I’ll go fire Tyler and Julian immediately.

      1. Little did they know that the patch notes for 11.20b3 would ultimately spell the untimely demise of Laminar Research.

      2. I just did that. I can’t believe I used to have 40-80 FPS on 11.10 on Linux and now with 11.20b3 I am getting 8-10 FPS. Something is terribly wrong somewhere in the pipeline, I hope it gets fixed soon!

      3. The 11.20b3 windows exe run in wine runs with 50fps in ksea at lowest settings (native 11.10 ~80fps).
        Something in your linux layer broke?

  4. Hi Ben! I just found out that the DRAG_GAIN instruction is now deprecated for vrconfig. Is there any guidance available for the vrconfig.txt file format and associated instructions syntax?
    Thanks!

  5. One interesting thing. I have been playing with VRconfig.txt’s and I have one with an error in it. Up to now I’d get a message “this vrconfig is invalid” or such. Now, the message is “This scenery file is invalid… the scenery may not look correct”. I filed a bug.

    1. +1
      I noticed that the context is described as a scenery error also. The good news is that the error messages for VR are now more verbose, and you can track the error down to a line number in vrconfig.txt. So, if you ignore the erroneous “scenery” context, the bug reporter is pretty good…

  6. Hi, is there any updates on the Linux issues? I’m on NVIDIA 1070Ti and an i7 8700 overclocked to 4.8 GHz, and I still get framerates of 8-10 fps no matter what I set the graphic settings to.

    This occured in 11.20 – 11.10 was fine. Have tried “everything” – disable plugins, change plane models etc etc but the performance is still awful.

    Other than that the updates look great – just that I can’t fly because flight times are at least the double of what’s normal because of the low frame rates…

    1. i have new this problem i good 30-45 FPS now in the 11.20b3 low fps 15-20 🙁

    2. I’m on Windows 10 using a beat up GTX690. Was running nicely on beta 2 at 30+fps but now I’m seeing 9-12 fps on average especially when looking out the cockpit window. If looking down towards the fuel selector inside the default Cessna, I can get 50-60 fps.

  7. With the upcoming “widget-based UI in VR” will that need a updated SDK?

    Will any of the old widget code be usable?

    Are you any closer to finding the FPS killing issue on some Linux machine?

    Thanks Bill

    1. There will be an updated SDK, and you’ll have to do:
      1. a simple opt-in procedure to tell us that your widgets are “modern” and VR safe. Basically, we’ll back your widgets with the new XPLMDisplay code paths IF you tell us it’s cool. Since we can’t know if your code is safe for this, it’s opt in.
      2. if you have any unsafe code in your widgets, you’ll have to fix it. We’ll have a technote on guidelines – DRE and PluginAdmin “just worked”, for what it’s worth.
      3. You’ll need to call an API to put the widget window in VR – just like XPLMDisplay.

  8. LOW FPS 15-20 in 11.20b3 update

    i have now low fps in all airpot and aircarft

    Before i update 11.20vr6 it better good 30-45 FPS
    i haven a good pc… here my date

    win10
    x-plane 11.20b3
    i7 7700k 4,5 ghz
    navida gtx 1080ti
    2T SSHD hard disk for x-plane
    32GB Ram 3200mhz form g-skill

    x-plane setting graphic:
    Visuelle Effekte: high
    Quality of textures: maximum (255MB)
    antialiasing: 2xssaa+fxaa
    shaddow: off
    Number of World Daycare objects: high
    Detail level of the reflection: low
    Show parking planes: off
    Flight model calculation probuild: 2

  9. Hypothetical question re: multiplayer/multi-system. Would the synchronization between two different PC’s be sufficient to render each eye of a VR environment individually, aside from the fact that at the moment no such VR HMD exists to take advantage of such a configuration. Let’s consider the PC’s to be co-located and connected via the fastest possible networking connection, running identical installs of X-Plane, and totally stripped of extraneous background processes. Just thinking outside the box a bit. It’s a bit chilly out here, but it’s also where the fun ideas are. 😉

      1. Then… what about a situation with two GPU’s instead of one in a single system? Again, hypothetical, and non-SLI. I imagine it would take very special code so that an application would render one eye on each GPU. Clearly I’m not as well read as other users about image rendering and GPU capabilities, but if Vulkan/Metal push more of the heavy lifting to the GPU, then systems with a pair of monster video cards would stand a better chance of driving higher that resolution HMD’s that are coming down the road. Just wondering about the way forward, since one PC now has to do what largely appears to be the work of two in VR.

          1. You knew this was coming… 😉 Any chance this may make for a crack in the “X-Plane doesn’t do SLI wall?”

            Of course the GPU vendors are going to advocate for anything that further increases their production backlog caused by Bitcoin miners.

            But it does seem like a potential way of adapting systems to the VR challenge, rather than having to find every last erg of efficiency via the code alone. Then again, in a few years maybe we’ll see a something happen internally to a single card to optimize it for VR along the lines of SLI, and instead of taking up two slots on the mobo, the VR cards will take up three. Always maybes in the future. 😀

          2. I did…I’ve been pre-emptively drinking. 🙂

            Seriously, here’s my view:
            1. Multi-GPU is not insane for multi-eye and multi-monitor. (By comparison, I consider two GPUs for one single frame to be like two cooks sharing a single frying pan – a ton of effort and awkwardness to get an improvement that really isn’t super useful.)
            2. When we finish our Vulkan work and we have an abstract graphics interface, we can look at multi-GPU…for the first time it will be something that could be sanely coded (albeit at some cost to developer time to only help the small percentage of our users who have TWO huge GPUs). Before Vulkan with OpenGL, we don’t want to try that bolt-on. I’m still skeptical that this is the best investment of our dev time, but it’s a cost benefit analysis after the Vulkan rewrite, not a crap show.
            3. F– bitcoin. I think if we didn’t have these historically highly abnormal GPU prices due to the crypto craze, multi-GPU would be less of a concern because we’d all be going “a GPU is coming after the 1080, and I’ll buy it to do VR”. Now we’re all going “I can’t even afford a 1070, I’ll never have the $10,000 to run a 4K VR headset on a single GPU.”

            My hope is that by the time the headsets up-rez the crypto-bubble will have burst and we’ll all be able to buy used 1080 Tis that have been in continuous max use for 3 years straight for $7 on eBay. Sure they’ll burn out after 2 hours, but you’ll just swap it out for another one. At least, that’s what Sidney says. 🙂

    1. Not in DRE. A lot of datarefs meant for OBJ animation take on the value of _the controller being drawn_. When they are read outside drawing in DRE there is no current controller and thus they are 0.

      This is a good indication that they are NOT for general use!

      There is no API or interface in 11.20 to let you get controller info, nor will there be in 11.20. We’re not ready to build that API yet.

  11. Re: Beta 11.20 B123
    1)Could Mac’s ( ATI 1GB) be affected in a similar way to Linux ? Experiencing noticeable erratic 50-20 FPS drops with some aircraft , LR Cirrus as well and scenery ( default ) jumping even at 30-40fps (v-sync:on) all medium graphics no shadows/reflections. 11.20vr6 was fine
    2) Do all 3rd party planes now have to be updated post 11.20VR6?
    3) Is there updated minimum Mac specs for 11.20
    Many thanks

    1. I’m experiencing the same problems on Win10. That’s very strange and inexplicable as my setup did not change since I updated to 11.20 b3. Anyone else?

      1. I had to reduce AA by 1 point to get the same performance. Not very critical, but still …

  13. I found the same performance Issue since the Upgrade to 11.20 beta from VR preview, however, it seems it is linked together with XEnviro somehow. After disabling XEnviro completely, the performance on the SF50 was fine again, 60-80 fps, with XEnviro only 15-25, before it was around 40-45 with XEnviro.

    Some change in the beta seems causing a performance decrease, at least, together with XEnviro.

    I am using a Win10 setup, Nvidia 1080, 16GB with SSD only.

    1. I have seen the same thing. I have seen that with xEnviro it sudently drops to below 10 fps. If I then hit CAVOC in the xEnviro menu I go up to 40 to 50 fps.
      It is a shame because I know that the xEnviro developer is chasing issues that commes up after every XP update.
      I really hope that LR and xEnviro is talking together.

    2. It’s interesting that I also suddenly started having performance issues starting with b1, but I don’t have xEnviro. However I normally fly with addon aircraft, and yesterday I flew with the Cirrus and again had good frames…

      So I’m wondering if maybe something happened with the plugin API… don’t know…

      All speculation anyway 🙂

  14. I had a chance to fly the 172 G1000 for a few hours on the new beta and the co-pilot MFD brightness was a ton better. Unfortunately, my FPS is still throttling and causing jitters in the HMD. I am able to regulate it by locking ASW at 45fps and the Lua script adjusting LOD to achieve 45fps minimum. When I run on Auto, the FPS surges back and forth between 50-80 depending on the area. I’m not ruling out other factors such as drivers, etc. I’ll keep testing. i7 6700 @ 4.4ghz, 16gb, 1080ti with Oculus CV1.
    Seriously, I could not be happier since you guys have added VR support to the sim. It is a dream come true for me. Keep up the good work guys!

  15. Bit off-topic here…
    Will X-plane support the new Vive Pro headset “out of the box”? Or is the new Vive Pro a totally new headset to be dealt with?
    Just made a preorder for the Vive Pro. Should start shipping 5.4.

    Looking forward using it with X-Plane.

    Thanks,

    Mark

Comments are closed.