It’s been a while since I have posted about what the team is working on, and given all that has happened in the last few weeks, it feels like a million years. Here’s a run-down of…stuff.
X-Plane 11: Beta Time
Today we are putting out X-Plane 11.51 beta 1. This is a bug-fix patch for X-Plane 11.50 with a handful of random fixes that we have accumulated over the last few weeks. Release notes here. You will not be auto-notified of this beta–you have to pick it in the installer if you really want it.
I expect the beta to be relatively short, as we’re just trying to put out fixes for things we’ve found since we’ve shipped 11.50, improve diagnostics, reduce crashes, etc.
11.50 beta 1 does not have new Gateway airports. We’ll include them very soon–probably in beta 2–we had a few last minute snags, so I pulled them out of beta 1 to avoid delay.
Road Map: Graphics and Performance
X-Plane 11.50 represents the first step in our long term performance road map: moving to modern, low overhead, high-performance rendering APIs. These APIs are multi-core friendly; for X-Plane 11.50 this results in better overall FPS and smoother performance, but only an incremental increase in multi-core use.
One stealth performance feature in X-Plane 11.50: plugin object instancing. X-Plane has had an instanced drawing API for several years now, but with 11.50 we saw widespread plugin adoption. This is going to be very important for performance going forward; the instancing APIs are designed for efficiency, particularly in a multicore environment.
We have now switched gears and we are working on new features in the engine itself, e.g. we are working on what we draw and not so much how we draw it. In other words, we are working on graphic enhancements, new features, etc.
The new features are, as they are being coded, already taking advantages of new tech made possible by Vulkan and Metal, e.g. GPU compute kernels, GPU-based culling, etc.
Once we finish rendering features, we can pivot back to performance and push hard on multicore. The next multicore goal is to be able to render multiple views in parallel using multiple cores. Parallel rendering has several benefits:
- An X-Plane frame often has sub-views rendered to form the main view (e.g. shadows, water reflections, cube maps, in-cockpit cameras, etc.). Any concurrency we expose makes the sim faster in these scenarios, and they are common.
- Right now while multi-monitor is possible with X-Plane, it is very expensive performance-wise. Having a frame that can be farmed out to multiple cores would make multi-monitor less of a performance hit.
Note that multi-core multi-monitor would still be single GPU, and it would be a win because right now CPU time limits multi-monitor setups.
What about multiple GPUs? That’s something we’ll have to look at after we have multicore on the CPU–without it second GPU support doesn’t help.
Big Sur & the Mac
There’s been a lot of Apple news this week that’ll have to wait for a separate post. We recommend waiting on Big Sur for a few days until we’ve had a chance to test it a bit. Hopefully that’s an easy ask, as right now the download servers appear to be overloaded.
Been wondering what you guys have been up to. Now I know. Sounds great. If possible, can you expand a little on “ we are working on WHAT we draw”? Thanks yet again for everything. Cheers.
We’re not ready to release details yet, but I’ve been working on lighting for a while now – this is the biggest update to how we deal with lighting since PBR was added in 11.0, and it’s necessary to get a lot of other things we want to do right.
Sorry for bothering you, but what about the rain issue? During night flight we see Star Wars hyperjump. Honestly, this bug is annoying. Hope this issue will be fixed as soon as possible. Anyway, thank you guys for your great work 🙂
Woohoo! I could tell poking around some of the art controls that the lighting model was “awesome, yet subtly wrong” so this is good news.
Unrelated, have you poked around on Apple Silicon yet? I wonder how the UMA model will affect x-plane. It should really help in the “not having to shove data back and forth on the bus” side of things, but the graphics cores have quite a bit less raw horsepower than than desktop GPUs.
Yay!!! Awesome sauce!!
I very much hope that a top priority is to get x-plane working with the new Reverb G2 hand controllers. Menu items can no longer be selected using the new controllers.
Given the popularity of the G2 and the imminent release of VR for MSFS I would suggest that this is critical.
Please report a bug if you haven’t already so we can track it.
Please file a bug. We have a build + instructions to get more diagnostics on this controller we can send you.
I just sent in a bug report to you guys as I am also having this issue. Thanks so much for being on top of it, very excited to use the G2 in XPlane!
“The next multicore goal is to be able to render multiple views in parallel using multiple cores.”
YES!!
Wonderful to hear more news after the big Vulkan jump 🙂
If it can be made to use a separate core to render each eye in VR this will be huge in terms of VR performance. I really hope that will be the case.
at this point multi GPU is effectively dead with it only supported on the VERY top end of GPUs… so wouldnt bother with that at this point. everything else sounds great
There are still terrible graphics stutters when changing cockpit views or panning with the mouse etc.
This was supposed to be fixed in one of the last Beta’s.
However it is still very much a critical bug.
We have CLI flags to work around these stutters at the expense of additional VRAM, namely
--gfx_dsf_in_vramand--gfx_obj_in_vram. The underlying problem here is VRAM management and large (U)HD meshes, which have to live somewhere. For most users, even those with 8 Gb GPUs, it’s impossible to keep super high resolution meshes together with everything else in VRAM. You can easily blow 3+ Gb on just the mesh data, nothing else. To deal with this, X-Plane will simply not upload the non visible DSF meshes to VRAM and instead keeping them in system memory. When you look at a DSF that wasn’t visible before, we asynchronously upload it to VRAM and just draw the mesh out of system memory, which means the GPU has to fetch the data from there to draw. This isn’t ideal and leads to those stutters, if you suddenly look at 200mb+ of new mesh data, it’ll have to be transferred just in time for the frame. Which means that the GPU frame time will go up. The current scenery engine just can’t do any better in these situation, it’s either rendering just in time (meaning stutters), blowing up VRAM budget (blurry textures, or out of memory if your card doesn’t have enough VRAM) or just not rendering anything at all (pop in as you pan around). None of these solutions are any good.We have some long term plans on how to deal with this in the future. There just wasn’t any time in the already way too behind 11.50 time table to fully solve this issue.
What about with the new GPUs with 20+GB vram?
Use the parameters mentioned?
I believe this is exactly the case when you can use those command line flags to force X-Plane to keep meshes and objects in VRAM.
Yes, well, I was sort of thinking that they might have just used more VRAM automatically when the available vram is so much greater.
The reason for having this as a opt-in parameter works well for a card with 8 GB, but not for a card with 24GB, to my ears.
The problem is that you can also load up the sim to fill 20 gb of VRAM. Loading everything into VRAM is a strategy we tried for big cards early in the 11.50 beta, but as it turns out, some users have crazy third party scenery (and aircraft).
This was one of the biggest issues we had while working on Vulkan and Metal, X-Plane is crazy extendable and there is not really a hard limit of what you can throw at it. X-Plane has to do its best to cope with that, while also dealing with the fact that it has to manage the VRAM itself (and share it with other applications too!). This is unlike traditional game development, where all you have to do is get the level designer and environment artist into your office and yell at them to lay off the 4k textures for just one damn second and to reuse some props. I remember spending weeks on the VRAM streaming and management code and having out of memory errors haunt my dreams.
That is not to say that X-Plane is perfect by any stretch by the way. I agree, cards with lots of VRAM should in theory work automagically with heavy scenery. The practice is unfortunately more complicated than just that. I think we have a solid long term plan for how to deal with this, but unfortunately that means that for now we are stuck with the “somewhat okay” solution + CLI flags.
Wow, I tried out those parameters with my 2080ti which has 11gb of VRAM. I had bad stutters in VR from time to time that I couldn’t get rid of no matter what I tried and those options fixed it. Thanks for that.
So can I simply type “x-plane.exe –gfx_dsf_in_vram –gfx_obj_in_vram” in the command line window or do I have to separate the flags somwhow?
Flags need to be separated by spaces only.
Code needs a major refactor. Back to the drawing board!
Is having faster normal RAM (3600 vs 3200 e.g.) and having a faster bus (PCIe3 or 4 vs 2) an advantage here?
If you had 8 GB of VRAM would you enable both of those flags or just one and which one would be more beneficial? My VRAM profiler says 4-5 GB used so I think I can spare some.
The DSF flag is probably the one that will alleviate the most stutters, but also the one that will cost you the most amount of VRAM. Try it in some heavy scenery with heavy terrain meshes and see if it blows up or not.
I have an iMac with a Radeon Pro Vega 48, and this setting works well. Some 737 textures in the cockpit don’t render (primarily the fms and engine display) but this is neither a complaint or a bug report, I am just messing around.
Its pretty cool to see this stuff not stutter at all.
During latest flight the cockpit stuttering is just terrible. Vulkan is not even useable like this. There needs to be a fix developed urgently. Also still experiencing brightness changing when zooming with the mouse. And also “holes” or “tearing” between ortho layers (a long time issue).
There was a LUA script (LFD’s Auto View Distance) that was making the excessive stuttering. I have removed it for now. The stuttering is less noticeable, but there are still some micro stutters when changing views.
When will you be implementing VR Single-phase rendering? This is a feature of Nvidia cards allowing the vr image all be done in one draw for both eyes. They have implemented this on most other games and P3D and it keeps VR frames high.
Honestly this is not at the top of our todo list. X-Plane _already_ uses hardware instancing to draw VR. There are four costs to ‘going stereo’ in a rendering engine:
1. Preparing multiple pre-pass buffers (water reflection, shadows). This is not an issue for VR – the eyes are so close together that shadow maps are reused between eyes.
2. Issuing twice as much geometry. X-Plane already works around this by using instancing, so there is no CPU overhead to VR. Without this we wouldn’t have VR.
3. Transforming the vertices twice. This is only fixed by NVidia’s “multi-view” and other extensions. We pay this cost in X-Plane.
4. Shading both eyes pixels. This is an unavoidable cost of VR, but can be made better by e.g variable rate shading to avoid overshading pre-lens distortion. We don’t do this but we intend to do it in the future, and it’s probably the highest priority “clever VR trick”.
We can measure our scene and see if doubling vertex shading is actually a big deal for VR, but I don’t think it’s going to be that important or some kind of magic bullet – all VR apps need _some_ kind of way to render twice, but instancing seems to work pretty well for us.
How about variable rate supersampling? It seems to me that this can be a big contribution in managing the GPU load. Avoiding stuttering by adjusting the rendering resolution to GPU workload.
I think VRSS is going to be really useful for VR and some future rendering. I don’t think it will help stuttering – the stuttering we have now is based on changes in frame time as content is moved from system memory to VRAM.
Is having faster normal RAM (3600 vs 3200 e.g.) and having a faster bus (PCIe3 or 4 vs 2) an advantage here? (duplication of this question, sorry 😉 but it seems relevant in both locations)
Checkout RTX IO, skips the whole system memory deal. Straight from hard disk to VRAM. No more excuses for VRAM and bad performance with XP, period.
Ha…the very first product I worked on over twenty years ago had that capability – wasn’t in the computer graphics space, it was a custom board and we thought it was very exotic (and we charged a ton of money for it). Nothing is new in tech under the sun.
But..what problem do you think this solves for X-Plane, exactly?
VRAM / stuttering issues when there is max objects / load on the GPU. Need RTX IO plus DLSS etc for better performance. I’m sure JustSid can agree!
The stutters come from having to draw frames using _geometry_ that is in system memory, not VRAM. DLSS and RTX IO are of no use for this case.
People comment on this blog with lots of questions about the alphabet soup of extensions that the IHVs come up with, so I want to be clear about what will and won’t actually make a difference for the real experience in X-Plane.
Glad to finally hear some news from you guys.Have been super quiet past couple of weeks.Looking foward to the future improvements.
For now however, i see the strange light scattering at dusk from high altitude is still present.A halo forms below the aircraft at dawn/dusk.This ruins the immersion and would be glad if you fixed it soon
Will the graphical enhancements be X-plane 11 or 12?
I was going to ask the same question.
Lighting if improved will be the biggest game changer for Xplane!
Crazy that they are still
Improving their lightning since xplane still
Had the best
Lighting of any sim.
The setting sun, which illuminates the cockpit from behind through mountains and the plane?
There is indeed still room for improvement and I very much welcome the fact that work is being done on this.
XP is a good (maybe the best for home users) flight simulator. But there is not need to lie. It can be improved in many ways on the visual aspect, is far from having the best lighting yet.
Terrific job, Ben. Congrats to the team.
The sutters reduced a lot here. I´m on maximum objects number settings and still very fluid.
Uh… looking forward to your upcoming apple post! 🙂 Can‘t wait for an Apple Silicon native x-plane.
Hello and congratulations on your work, As I understand your article most multicore implementations may vary your hardware preferences in case one needs to buy a new computer. I understand that it will no longer be advisable as now to rely on a processor that gives the maximum in single core, but it will become even more useful than now to have a processor that as well as fast also has as many cores as possible. From tests made with our “extreme VFR” project (very high definition of minor tracks mainly used by ULM), it seems that currently, with the same GPU, having a processor with more than 8 cores is of little use, while it is very important to have a frequency processor as high as possible.
It would appear from your article, that with the next developments you describe, this will no longer be the case.
I ask her if I have interpreted her words correctly.
To be clear, and to give an example understandable to those who read us, I recommend in the near future to transition my x-plane from a ryzen 5 3600x processor to a ryzen 9 5900X (from 6 cores / 12 threads to 12 cores / 24 threads)?
What cost / effectiveness ratio will have more cores, compared to what cost / effectiveness ratio does it have now to have a higher processor frequency?
Forgive my bad English but I am using a translator.
Thanks in advance for your kind reply.
Ermanno Cavallini
I don’t think it’s critical to get from 8 to 24 cores right now. But it’s definitely worth it to be in the 8-12 range and not 4-core range.
Not specifically having any experience with Ryzen CPUs, you might also consider turning SMT (Hyperthreading) off to see what happens. If single-core performance is limiting (which today it is) you’ll get better single-core performance with it off. Question is only whether the benefits of the 12-core machine outweigh the benefits of better single-core performance with SMT off (and only 6 cores total). You won’t know till you try, but it would be interesting to see what your experience is.
I run a 10-core intel machine with Hyperthreading turned off; makes a significant difference for me. (I don’t need 20 cores…)
Anything else to be shared with some more specifics on the graphics part? All i read about was multicore multicore and multicore.
It has been more than a year since a certain competitor came back, showing how graphics is not just for eyecandy but can be relevant also for immersion (and what better thing than a simulator to immerse yourself in the simulated environment).. I wasn’t hoping for screenshots but something more than “we are looking into that at some point in some way” would have been appreciated..
Hi Francesco.
What I read between the lines is that they need the multicore stuff to be in place to achieve (planned) improvements like lights and ( a lot of) other “things they can’t tell us about just yet”.
I don’t think any flight sim dev haven’t seen the amazing graphics of Msf$ already.
On the other hand said sim looks terrible in other ways, not to speak of handling…
Depending on how much time LR needs to make things shine, I think I stick around 🙂
No that’s backward – we’re doing visuals first like lights, then back to multi-core.
excellent!!!
Might be like that then, Chris. I would stick around no matter what, and i reckon every sim has its strong point. However what i am saying is that graphics nowadays has an importance no matter if it’s a “professional flight sim” or an entertainment flight sim. Both are being sold on Steam to the same audience, both requires certain thing. That is why i am eager to see something concrete about it.
I am fairly certain that a change to lighting and clouds, like it looks like we are going to get, is going to be game changing visually 🙂 And a fix to glowing trees.. And water.. so fingers crossed!
can you do something about the washed out look in vr , it would be nice to be able to adjust things like gamma , contrast and colour etc etc
Install FlyWithLuaNG and then VMI Twick. Play with the sliders in the weather section. There are sliders in there that brighten things up and change hues and such. Can all be done while flying in VR.
Or tune it in your GPU config
gGive us more frequent development information. Long silences are not good. We want to see what xplane 11 will do against fs 2020. I hope you are on the right track.
Hi Ben, thank you for the update. Is there any possibilities of taking librain or something similar under your wing and natively support that functionality in 11.5x vulkan??
How about a decent weather engine?…will be great.
I cut my multi monitor use just prior to the .50 beta because of performance. Very much looking forward to going back to it.
Thanks Ben, Austin & the rest of the LR team for all your hard work!
I increased my multi monitor use because of Vulkan’s performance increase. I can do 3x4k monitors are close to 30fps on a 7700k cpu and 1080Ti gpu, it’s glorious for immersion, and not something MSFS can do.
what is going on with multiple views with different monitors ,,
IE having cockpit view on one,, and outside view on other etc..
That’s not something the sim does right now – what’ the use case where you want this?
Here’s why we don’t do it: _where_ is your virtual “head” when this is happening? What _sound_ should we play? X-Plane’s view model is multiple views from one single central virtual head location – hence camera offsets/rotations but you can’t be in the front and back of the aircraft at the same time.
For an external camera it would be perfect though since you don’t have to change either view nor sound direction.
(Ben, you should know this was expected as a comment) 😀
The goal of improving and optimizing the multi monitor is fantastic for a simulator. It has already improved a lot in terms of fps with 11.50. You are doing a great job. What are the expected times?
Hi LR people 🙂
I want to ask more directly:
Do you have planned to improve helicopter “experiences” ?
I think you know I’m_not_talking about plane handling.
I keep asking stuff, but haven’t seen any real straight answers.
The suggestion of “triggers to scenery” would be ONE amazing new thing for helicopter stuff —>
https://feedback.x-plane.com/posts/747/triggers-to-scenery
I wish I understood a quarter of the discussion above!
I am a humble Mac user who has tried Catalina once and gave up in frustration; it was great however for people to pull together to sort out the work-around.
Now we have Big Sur(?) and I was pleased to see it mentioned above. For us Mac users, it would be a great service if LR could itself come up with a work-around (if needed) that we could all use.
I’ve been racking my brain, trying to figure out how to program/open X-Plane aircraft doors from outside when the builder of the aircraft has them with opening doors. Something like very good in FSX…i.e. control e, 1,2,3,4, etc.
Honeycomb Aeronautical Bravo Throttle Quadrant and HP Reverb G2 VR headset are two major hardware that is coming out this month.
At the moment both of these doesn’t work fully out of box. Will there be a driver patch to support functionality of these new hardware?
My guess for the Bravo is the throttle gets a joystick config file to make it easier to deal with, but the output side (LEDs, etc.) will need a plugin – that’s just how X-Plane and HID work.
What’s _not_ working with the Reverb G2 right now on SteamVR?
G2 is the next revision of WMR. At the moment issue is with controller. The thumb stick and button doesn’t work (trigger works). WMR revised controller config file is needed.
See this video from VR Flight sim guy that discusses this at the beginning https://www.youtube.com/watch?v=GGEFTo1VMPc
Let me know if a bug should be filed for this.
Please file a bug. We have a build + instructions to get more diagnostics on this controller we can send you.
Ben, G2 controller mapping problems apparently. See https://forums.x-plane.org/index.php?/forums/topic/231331-hp-reverb-g2/
Please file a bug. We have a build + instructions to get more diagnostics on this controller we can send you.
Bug report sent
Hello Ben,
First of all, many thanks for this update. It’s really great to see to progress in X-Plane. It’s an awesome piece of software which gives me a lot of joy in life.
I have one question, since you are looking into improving the multi screen support. I run X-Plane using two screens next to each other. They both have a resolution of 1920×1080. Until recently I configured them in X-Plane as two seperated screens which worked quite well. However, the FPS hit wasn’t so great. I changed the configuration now and use just one monitor with a custom resolution of 3840×1080. It works great, but there is a minor problem. All dialogs are actually displayed right in the middle of my two screens and I cannot move them. Whould it be possible to display dialogs in future always on the left side of the screen instead of in the middle – or even better – make them movable 🙂
Many thanks,
Marco
Mmmmmmm…interesting request. I’ll talk to Tyler about it. Did you get the one big monitor via an NVidia control panel or X-Plane settings?
I use the X-Plane settings.
guys can we address the multiplayer issue now? Please? I’ve been advocating this for years now. All these other flight Sims have multiplayer over the Internet but x-plane is so sorely lacking in this respect. do you think we can get this in the new development cycle?
Pssst
I agree. I’ve been hinting about this for a while.
It works of a fashion, but it would be great to get an overhaul.
Ultimately the data should share aircraft model and livery.
Where static aircraft are selected, these should match. AI too.
Thanks for all the advances of late, this is very much appreciated.
What about Big Sure? Some add-ons like JAR A320/330 under Catalina 10.15.7 are causing XP to crash on iMac. The developer asked to follow some steps to bypass the private security that maybe can influence now the transition to Big Sur?!
The security isn’t going to be any lower. I don’t know what security-bypassing steps the author is recommending.
This is all great news. I run a 3 monitor setup, 2 x 4K (running at 1080) and 1 x 1080 native all on a Radeon VII in an i9 Hackintosh (64gb ram). I can eek out 20 – 32 fps with moderate to high graphics settings (stock scenery). Pre metal, this just wasn’t even close to being usable. The immersion factor of 3 monitors is fantastic. Hopefully a multi-core enhanced app would see a fps boost.
In a thread called “Stuff we are working on” I didn’t expect to get 2 questions about helicopter stuff deleted.
I didn’t use unpolite words or yelling.
I can try to guess the reasons but I would rather hear some answers or be told that helicopters are so low in priority that you will not answer.
No body deleted anything you wrote. The spam filter ate three of your posts and several by other people – I’ve moved them out of spam and some are awaiting moderation in the case where they are on someone else’s post. I deleted _one_ of yours that appeared to be a second posting of the first post (they had both gone to spam originally).
I don’t have anything to tell you about new features for helicopters right now.
Thank you.
Nothing as annoying as upset users that complains about stuff that’s out of your hand, right? 🙂 (Sorry)
“I don’t have anything to tell you about new features for helicopters right now.”
I knew I should have asked Austin to co-op on this question…..
As in “but………….” or as in ” ¯\_(ツ)_/¯ ” ?
Helicopters is (right now) a big plus compared to “that other sim”.
I really hope for some love feature-wise.
I was brave enough to upgrade to Big Sur. From a performance pov I carefully checked before and after, and it is about the same for me. The problem is that scenery load time is up big time: whenever I switch scenery location, it takes from 2 to 3 times what it required in Catalina. Btw, I’m not talking about the first load of the app, I’m talking about loading XP and switching scenery moving to other airports while in XP.