For the last few weeks we’ve had the Vulkan/Metal version of X-Plane in a private test program with third party developers, letting them kick the tires to discover the limits and bugs in our plugin compatibility code.
While the initial bridge to connect OpenGL-based plugins to X-Plane worked pretty well, compatibility wasn’t perfect and we had a few bugs. We also realized that we needed to change the design of that bridge to get much better compatibility. That rework of the bridge is now done and things are looking quite a bit better on all fronts.
We found one unexpected result from this redesign: when we finished rewriting the bridge, we ended up with code that could, in the case of Vulkan only, be used for 3-d drawing. This means we can now support OpenGL-based weather/cloud plugins from inside a Vulkan render, which we did not think was possible before.
The Skymaxx and xEnviro developers are in our private test program and have been great about jumping on new builds while remaining radio silent while we test this new tech. I am pleased to now be able to say: it works!
Those pics are a special build of SkyMaxx running in 11.50 in Vulkan mode. No more having to pick – you can have your third party clouds and Vulkan at the same time.
The Details: Vulkan, not Metal
3-d drawing compatibility will be available for Vulkan, but not Metal. The technique we are using is not available on OS X, so running a cloud plugin on Mac will require the OpenGL driver, not Metal. This isn’t something we can fix with some future bit of cleverness – it’s a limitation of OS X’s APIs. (We would revisit this if Apple introduced a new API but I do not expect this to happen.)
To be clear: on Windows what we are supporting is 3-d OpenGL drawing by plugins inside the Vulkan renderer, not native Vulkan rendering by plugins inside the Vulkan renderer. Native Vulkan rendering by plugins is an incredibly complex SDK problem, and not something we are looking at for 11.50.
2-d Drawing Just Works; 3-d Drawing Requires a New Plugin
For plugins that draw in 2-d we’ve gone for a “just works” level of compatibility; while we have seen some plugins that need to update due to illegal techniques and bugs, our goal is that a well-authored add-on just works even when Vulkan and Metal are in use.
By comparison, OpenGL drawing inside Vulkan is going to require plugin authors to sign up for a new 3-d drawing callback. We’re making this opt-in because, during the beta, we’ve found a lot of add-ons using 3-d drawing callbacks inappropriately, and 3-d drawing callbacks are no longer free. By requiring plugins to opt-in when they _really_ want 3-d drawing in Vulkan, we should get better performance.
The new 3-d drawing callbacks are really only meant for custom drawing like clouds. Other techniques like adding objects to the sim and drawing markings are better handled with other APIs. Our plan is to have detailed guidance on what technique is best for developers by the time we are ready for public beta.
Very good news
When is the Public Beta going to be released ?
Soon I hope. We’re aiming to do a private beta 7 next week with the new texture paging and if that goes well, it should be real soon.
Awesome update! Thanks Ben. Sounds like good progress is being made and I love it when it results in such positive “side-effects”!
Ben, thanks for the update.
I’m sad about the implications for metal but maybe you guys can just buy/hire both someday and Sherlock it into X-plane.
I am super excited. I won’t pester you about the public beta, but just know my heart jumped when I got the notification in my rss reader of a new blog post.
I hope your CDN bill is all paid up because when you do release, yikes!
Approximate date for Vulkan?
At this point in time when do you think public beta will be available to the masses?
So if you don’t use third party vendor such as SkyMaxx and xEnviro for cloud drawing, but utilize native X-Plane, it should “just work” with native Vulkan? And how would Linux meet Vulkan?
Native cloud drawing will just work on Vulkan, Metal, GL, everywhere – that has always been true since day 1. There was never a risk that internal x-plane rendering wouldn’t work because our code runs on the native driver.
Linux runs Vulkan, so in theory, the bridge will just work. If there are driver bugs specific to Linux then it won’t.
“Soon”
Anyway, as it happens often, MAC users are left behind due to Apples limitations. When you say Metal needs to use the GL drivers, I am confused. Specifically, will it be possible for Mac users (via some other way) to use this cloud feature too? Or will Sky Max not be usable on Mac ?
Will there be any other limitations for Mac users? Scenery add on airports or airplanes? While getting better performance is great, it may not be worth it if add ons wont work or take months to be updated
SkyMaxx on Mac will require X-Plane to be using the GL driver, not the Metal driver to run. This is the same as what we expected from the beginning of the Vulkan/Metal private beta.
The only Mac-specific limitation I can think of is that this new hook for 3-d drawing under a modern driver for cloud add-on plugins will not run on Mac. So it would limit other weather-drawing plugins that are adapted to Vulkan and OpenGL only too.
Hi,
no expert but Apple has a Metal OpenGL interop sample.. “Mixing Metal and OpenGL Rendering in a View“.. isn’t that all that is needed for supporting OpenGL plugins on Metal?
thanks..
Just to clarify, we already do have OpenGL and Metal interop through our existing bridge (same as we did before this announcement). This bridge on Metal supports 2D drawing only though, so that includes aircraft panels as well as window/widget drawing. What doesn’t work is the 3D drawing support that Vulkan now has. For that we would need a way to share our depth buffer. Unfortunately the sharing mechanism, IOSurface, has very limited support for what can be shared (it essentially boils down to 2D rectangle textures with a small handful of colour formats, no depth formats). There is a more high level API as well in Core Video, where sharing of data would go through a CVPixelBuffer. Unfortunately that one is just a very slim wrapper over IOSurface and has the same caveats as just using an IOSurface directly, ie no support for sharing a depth buffer.
Thanks for the input Ben
That last sentence could be read as you do not cover Linux in the private beta. I hope that is not the case!
My assumption is, whenever I read Windows in your Vulkan posts, I can safely substitute it by Linux.
Linux _is_ in the private beta – the private builds are for three platforms and there are a lot of Linux users. The thing to note is that Linux is a tiny fraction of our overall user base (< 2%) but represents a disproportionately large part of the beta program because a lot of third party devs are using Linux as a dev environment. I'd guess we might be 25% linux inside the private beta, which is devs-only. This surprised us at first - we knew there'd be "extra Linux" but we didn't expect that much. Those devs have definitely caught and reported Linux bugs. The issue with the 3-d drawing callback is that the weather add-on guys we have in our program are Mac/Win (SkyMaxx) and Win-only (xEnviro) so neither of them have tried the bridge on Linux. If anyone out there _is_ writing a Linux weather add-on, they should ping us, but we just don't have the real world test coverage. Given the bugs we've found on Windows with plugin bridging and the OS-specific parts, I have to consider 3-d bridging to be untested compared to the rest of Linux.
Thanks Ben for your long and very informative answer to my “fear”!
I believe the only major weather add-on that’s Linux compatible is UWXP (which is also on Windows).
Thanks for the update Ben. Great to hear of the collaborations fuelling progress. Looking forward to testing your efforts.
IS THERE A CHANCE OF TESTING ?
When the public beta is released, you will be testing…
I am really excited that there is a cooperation between Laminar and xEnviro, yes I know that it is a 3d party, but xEnviro is a great product for X-Plane in creating realistic weather, if the two areas can be better refined, then the benefits for both are very high if they are far better intergrated together, and more efficient.
Totally agree with this. Glad it got worked out because there was a bit of concern around that in early rounds. This is indeed wonderful news.
I read an article saying Khronos partnered with Valve, LunarG and the Brenwill Workshop to create an SDK which brings Vulkan to MacOS and iOS. Can this effort be used by Laminar Research or is it not available? Google “Khronos Brings Vulkan to macOS, iOS, After Apple Refuses to”.
MoltenVK, the effort by LunarG, Khronos and Valve to bring Vulkan to macOS is unfortunately not usable by us. It’s not a real Vulkan driver, instead it implements a subset of the Vulkan specification on top of Metal. So it obviously still has all the limitations that Metal had. We already have a renderer backend that supports Metal natively, there would be very little reason to put an intermediate translation layer inbetween us and Metal. On top of that, the Vulkan backend as it stands right now, uses features that Metal/MoltenVK does not support. So adopting MoltenVK would gain us nothing that we don’t have, but we’d lose a bit of performance overhead.
I am so happy about the close and transparant contact between developer and customer! Very great, thanks for all your effort! Learning about the features of Xplane every day, as practising for my current license when the weather outside is mehhhhh. Thank you!
Constantijn
Happy LAPL TMG pilot
Great to hear things are moving forwards again and as you know we’re all anticipating the Vulkan release. You mentioned that both Skymaxx and XEnviro have been part of the private testing program, which are both great products although somewhat resource intensive. Are you able to disclose any indicative performance gains with regards to those products and the transition to XPlane with Vulkan, compared to Xplane pre Vulkan.
I am not, but I can say that I _expect_ them to have _no_ performance gains – cloud add-ons tend to be GPU bound and they’re running in OpenGL, so nothing here would make them faster.
The net win to the user is that their users may be able to run a Vulkan X-Plane with them, so the users can get the X-Plane CPU-side gains while running the add-ons.
Thanks for the update. I’m looking forward to 11.50 and all the future possibilities it will enable.
Thank you for the update. I’d not so secretly hopes this might be the case.
Any chance this means xenviro/skymaxx can finally get linux support?
I don’t think so. If they don’t support Linux already in 11.41 (where there is _no_ difference in platforms) this implies they are not on Linux because it doesn’t make sense to do a port of their tech for an extremely small percentage of our user base. (We have never seen Linux adoption break 2%. Ever.) . If anything, the Vulkan situation makes this harder – all of the existing difficulty of porting for Linux remains, plus there is a risk that the GL->Vulkan bridge could be buggy in ways unqiue to Linux (since it depends on some OS-specific stuff to share textures).
Our experience has been that the GL-Vulkan interop is buggier than the rest of the Vulkan driver – it’s sort of the only area where we’ve had to report things.
Thanks, on first reading it sounded like cross platform sdk things that didn’t exist before had been created, making it easier for them to support. Will you still be working on the lighting and weather anyway – or was this that?
I am still working on lighting and weather – that’s a long term initiative for the core sim itself.
I have low expectations for any weather improvements based on virtually unanimous end user requesting over the past decade plus. I sincerely hope you make some real headway in this area.
The lighting though, hopefully will be a quick and easy fix. The current dingy post nuclear war world of X-Plane has single handedly created a shader cottage industry, that gives people the lighting effects they desire.
That’s good to hear, Ben. Thanks for fighting the long hard fight to get the light right! 😉
What’s to prevent this becoming a crutch rather than a bridge? Is there an incentive for 3rd parties to put in the work to change to Vulkan if their existing openGL code is going to still work. What’s the performance cost to the end user of 3rd parties retaining the old slower api and not investing the time to update?
Im afraid this short term win could be a long term loss.
Two things:
1. The bridge is only for actual native drawing. So _all_ other use cases have better alternatives and need to be ported. That’s not changing. So for example, if you use XPLMDrawObject, you have to move to XPMInstance (which is now at least available for two years). There’s a carrot and stick for that. The carrot is that XPLMInstance works with particles, and the stick is it doesn’t work in Vulkan.
2. The second thing to note is that there _is no_ native Vulkan path for plugins, therefore this isn’t a crutch stopping people from writing native Vulkan code.
WE are stopping people from writing native Vulkan code – a path for the weather plugins we considered but decided against. Here’s the fundamental problem: Vulkan leaves a lot of graphics tasks that OpenGL used to do for us — managing memory is the big one but there are others. So to make an SDK for plugins to draw in Vulkan we’d have to have a stable memory management API on top of Vulkan that’s plugin ready that _is not going to change_ so that they can use it to interact safely with X-plane and not have their add-ons broken.
That’s tech we just don’t have – our memory management is still under development and we’re going to learn things in the beta that require changes. So we’re using GL for the cloud add-ons right now because a big chunk of the driver stack is effectively standardized inside OpenGL.
The other thing to note is: I don’t think Vulkan is necessarily a really good way for plugins to draw. Have you ever seen Vulkan’s “hello triangle”? It’s 1300 lines of code to draw one triangle. Without textures! The cloud add-ons tend to be bottlenecked on _GPU_ power and can keep the CPU side costs low relatively easily – that’s the case with our clouds too. And most GL drawing in X-Plane is 2d glass cockpits and UI. Vulkan is a very big, low level, dangerous hammer for this kind of dev. If anything, most plugin authors could use a _higher level_ graphics API, e.g. one that anti-aliases lines automatically, not a lower level one.
(Finally it’s worth noting that while we’ve had people offer to port to Vulkan, _no one_ has offered to port to Metal. The Mac is in a weird place – with somewhere between 25 and 30% of the user base, it’s big enough that a notable chunk of users care if it’s missing, yet it’s a real dev cost to port to it, since Vulkan and Metal are so different. So a cross-platform API like GL is a win…if you’re making a glass cockpit you can get another 30-50% growth in the accessible users by not using Vulkan.)
Vulkan is a win for us because we’re drawing the whole world and that process is often CPU bound and needs to be multi-core.
It won’t be a crutch because 3rd party cloud/weather add-ons won’t be required anymore in XP12. Right? 😉 😉 😉
Are you going to fix the contrail in version 11.50? Four lines of code in the shader make its color normal, white. Or do you have an agreement with the developer of xVision utility? “We will not fix the trail, and you can earn more money.” It was a joke.
Hello Ben, are Mac users going to see any improvement in performance with Metal. As stated earlier we do seem to be the poor relations in many things XP. I would be more than happy with things running a bit smoother
Yes – CPU costs are improved a lot with Metal – if you’re CPU bound you’ll get more autogen or you can turn on scenery shadows.
But beware – if you’re running at a huge resolution there’s a risk you overpowered you Mac’s GPU. In this case, Vulkan won’t help.
Hello Ben, how many CPU cores would be supported by the vulcan api running X-Plane? Is there a limitation of supported cores?
Will X Vision be compatible with Vulkan?
I don’t know – it depends on what they do. Reading back the frame-buffer and re-drawing it _does_ work (if done carefully) but modifying shaders or state in an unsupported way does not.
look carefully that you do not make a complete revolution of a good sky of a good sea and with clouds worthy of being called such (and not simple images) ms2020 will overwhelm you … do your calculations well! you are still with the clouds of 5 years ago maybe! give this simulator a twist!
Do you guys have or know of a good infographic that shows the relationship of Vulkan, Metal, OGL, and how you are stacking/abusing them? It would be interesting to see and might help some of us devs. Thanks.
Looks nice, are you guys planing to add more commercial airplanes like Airbus A320 , Boeing 777 and etc. cuz some third party addons doesnt work for me
Because in other words you simply don’t want to pay for them…
When 11.5 is released will it still be advisable to stay on MacOS Mojave or update to Catalina? Is there any advantage with MetaL on Catalina?
The update to Vulkan, the 11.50 will bring improvements in visual quality by default?
No. It’s a change in perf, not in quality.
If I understood this correct…
Aircrafts with 2D-panels will work as before even after the implementation of Vulcan and 3D-panels will, in some cases, work with issiues. Correct ??
Question then..
If I have an aircraft with a 3D-panel but also hardwarepanels with switches, knobs and encoders (that is I don´t manouver switches and knobs on the screen with the mouse coursor or some 3D-gloves plugin but through actual switches and knobs on my hardware panels), will that also work as before after updating to ver. 11.50 (with Vulcan-support) or will there be issiues as well?
Both 2-d and 3-d panels will “just work”. This is because the plugin drawing for a 3-d panel is the 2-d displays.
Your hardware panels should be unaffected too.
To Summarize, i could deduce to saying that the road-map to x-plane 12.0 is to finalize a *Stable Memory Management API* in order to pave-way for full stack Vulkan Support covering (Core + Plugins).
This further goes that OpenGL support for Cloud-Addons might or might not be needed for Xplane 12. This really depends on the strategic decision of Laminar as they lead the design and set standards for the next-gen platform.
We are not promising a Vulkan API in the future. We don’t know if we’ll do one. Stable Vulkan internals are _necessary_ for such an API, but not sufficient. We’ll re-examine when it’s not impossible. But as I’ve said in other comments, I’m not sold on Vulkan as a graphics API for add-ons.
The GL 3-d drawing callback that makes clouds work with Vulkan in 11.50 may not work in future major releases – we can’t guarantee the rendering pipeline won’t have changed a ton.
Great news!! What about VRSS, FFR and DFR for VR? It would improve fps quite a lot. Any news about that in vulkan xplane? Thanks
We may do VRSS someday – it seems like a nice way to get a FPS boost for VR and other scenarios. It’s not on the table for 11.50 though.
Wov, it looks a great oportunity. Many of us we only fly VR. Once you try it, there’s no return…
I understand the need to be able to handle existing plugins, so plugin compatibility code implemented is a need… but do you also provide Vulkan API’s? Third Party plugins will eventually need to be moved from OpenGL to Vulkan.. This will also benefit any x-plane 12 development because you may choose to remove the OpenGL compatibilty code and that will speed up x-plane further..
We do not provide Vulkan APIs at this time, and I do not expect to remove OpenGL plugin rendering for 2-d rendering callbacks in the forseeable future. It would be useful for X-Plane to drop OpenGL because Metal and Vulkan provide similar modern threading guarantees that are quite different from OpenGL, but we could run plugins via the bridge indefinitely. There’s no clock for people to rewrite their panels.
Hello Ben,
will this system allow for density and duration changes in the smoke system for aerobatic aircraft?
Hi Ben & thanks for the update.
I was worried that the team had burnt itself out, it’s been a very long and twisting road to get to this point.
Great to see the updates on the blog again.
I keep having to pinch myself when I remember this is another FREE update from LR.
Best regards to all of the Dev’s
Dave
Hi LR Team,
I do not understand why you spend your time and energy in solving compatibility issues with 3rd party developers that sell add-ons hacks that do not comply to the official platform SDK. You still support Open GL in x11.5, not need to fiddle around with this 3d crap under Vulcan/Metal.
Anyway, I think features such as Clouds / Atmosphere / Lighting / ATC / AI Traffic are core and should be exclusively accessible to x-plane itself. I understand why somebody developed on top of that dead FSX horse, but x-plane is not!
Regards,
Heiko
I agree! The team should focus their energy on moving to Vulkan for the core product. I bought X-Plane for X-Plane. Other than xPilot for Vatsim, I have no addons and don’t plan on getting any anytime soon. Think of the influx of cash from the AMD guys that can finally buy and run the sim with decent FPS. Unless they already bailed with the announcement of the *other* sim.
I kinda agree.
“We found one unexpected result from this redesign: when we finished rewriting the bridge, we ended up with code that could, in the case of Vulkan only, be used for 3-d drawing”
7 weeks without a word, then – besides some compability issues – the biggest news is that suddenly viola we got a 3D importer anyway, despite is wasn’t doable in the last post from 2019.
One COULD be tempted to think that quit a lot of that time went to assure that those who complained about their invest of 2 plugins got a lot for their money.
Well one can hope “we” get same treatment later on ( I would love some working hours spent on making a ground view monitor for helicopters)
You could think that. You can think whatever you want. Most of the time went into rewriting the plugin bridge itself.
@Ben Supnik:
It’s your sim, your working hours – and your coding (which I admire a lot, not being able to code anything myself).
I was/am just frustrated leaving us “alone” in 2 months after it was “almost there” in Dec. 2019.
Those people with the plugins must be happy like crazy, and you coders must be proud finding a way making it happen 😉
I am just sick after getting other things implemented in X-plane (yeah like the monitor view I keep mentioning) 🙂
@dave :
“The suggestion that LR shouldn’t support the plug in folks is…insane.”
That sounds slightly over-interpreted of what people actually wrote 🙂
Sorry, but your tone is one of entitlement. The devs are nice enough to keep the crowd up to date about what is about to happen, and this is much appreciated by all of us.
Please consider that we’re talking about a free point update which is about smoothness. All else is windfall from low hanging fruit.
I am afraid that this sort of cirticism in this place will just cause less information. You will not change the development schedule for 11.50 by commenting here. It is not the right place to complain.
I don’t think there’s any risk of this thread causing us to post less. The response to the paging post _did_ make me re-evaluate a little…one thing that was clear was that posting about texture paging _way_ in advance, when it was still a working concept internally without good data, and without easy ways to illustrate how it worked, caused a tremendous amount of confusion…basically no one learned anything and a lot of people freaked out. Sidney and Jennifer and I discussed it a bit and concluded that it made sense to blog about things when they were definite enough that we could be clear and unambiguous and explain the concept in concrete ways. So the weather stuff was in the works for a while, but we waited until we had seen a working prototype from Skymaxx and thus all the rules were locked down, etc.
I’ve struggled with wanting to respond to this or not for the past few days, but decided I can’t let this slide. The suggestion that LR shouldn’t support the plug in folks is…insane.
One of the HUGE selling points of X-Plan IS the plug-in support. I would argue that most folks use some sort of plug in or another, just because you don’t doesn’t make it worthless, and the “fiddle around with this 3d crap” is disingenuous. That fiddling around and discovering the 3d rendering benefit, as I understand it, came from recognizing that they needed to rework the bridge as a whole, the and OGL -> Vulkan3D drawing happened to be a wonderful side effect of that and not the core bit what they’ve been spending their time on.
All of those things you want, clouds/atmosphere/lighting/atc/air traffic? Those are all provided now by plug in developers if you want it. And because of that, LR can concentrate on “fiddling around” on things like….converting to Vulkan/Metal. Which in turn will allow them to do the clouds/atmosphere/lighting better than they ever could before with OpenGL. When it’s done, it’ll free them up to do the other stuff.
Do you see how all of this works together?
The next year and beyond is going to be super interesting in simming, and while I’m a X-Plane fan first and foremost for lots of reasons, including their transparency with us users about their development, the competition that’s ramping up is going to make it better for ALL of us. But if X-Plane is SO bad that you feel the need to berate the devs and minimize the ton of work they’re doing as “fiddling” then by all means, try another sim, there’s others out there. I’m sure none of them are just fiddling about…
None of above mentioned shortcomings during the xp 10/11 run has been really addressed successfully with 3rd party add-Ons – whatever free or payware product you take. And I tried a lot. All have big issues. And In the end everbody is frustrated.
Most likely because LR never positioned this as open for 3rd party. LR mentioned that over and over again. Do not address seasons with texture swapping. Do not replace shaders. AI Traffic is limited to 20 until further notice. private parameters are forbidden. Even flywithlua is not core and commercial products such as XPRealistic rely on it.
Aircrafts, scenery and external utilities is 3rd party business imo. planenaker and WED, perfect.
So yes. I think, it is better to stay with the product vanilla until LR provides Feature via updates or a new release.
I just want to be clear about a few things here:
1. I cannot speak to xEnviro because I am not familiar with its internals. But I believe that SkyMaxx is _not_ doing anything that is considered out of bounds for the various X-Plane SDKs. It is drawing using a 3-d drawing callback via the XPLM and reading datarefs. Totally legit.
2. When it comes to texture swapping and the terrain textures, we _want_ people to swap them. You need a license to derive your work from our textures, and swapping the runways isn’t supported. But the terrain library system makes terrain texture replacement straight forward and fully supported.
You are correct that we do not support shader hacking.
And to add: all of the features mentioned above (apart of seasons) are part of the product. And the attempts to replace/extend them is far beyond what the plugin system is capable or was designed for imo.
Will there be any improvement in the graphics section for xplane 11 in the future?
Looking forward to the Vulcan update breathing some last gasps of breath into my aging Xeon before I upgrade with the next Ryzen release. As a VR fanboy anything to kill stutters is appreciated, my eye candy is dialed all the way down to keep the immersion fluid.
If I want to look at pretty clouds I’ll stick my head outside, otherwise for VR if it is not unlimited vis it’s 200′ overcast with 3nm vis on final … bolts of blinding lightning with deafening thunder, bug splutter, crazy birds, wayward kangaroos and other wildlife worth dodging will increase the realism for me and could be worth the eye candy frame rate hit.
Till then, keep up the good work improving what matters!
How the paging file test went this week ? …and when we likely to see the this long awaited and anticipated patch, 2 years or so in the making ?
Sidney found a big bug on Friday that we are hoping was the last bug for internal build 7, which we will cut Monday if tests pass. “d7” has the new paging code enabled, so basically if it does well, we’re on to public beta. If it has big problems in private test, we’ll reconsider our life choices and drink heavily.
Ben…many thanks for your reply, fingers crossed. I am thinking but holding back for some add-ons atm as I need the frames for VR. Can I trouble you with one more question please ? Will it be beneficial under Vulkan to go from 16GB ram to 32 ? I am not on budget but like most of us don’t like wasting money on hardware I do not need. My spec is I7700 oc @ 5 GHz, 2080Ti. XP is on a M.2 EVO drive. I hope you can celebrate with a drink your success next week ! 🙂 Cheers, Michael
MY GOD YES going 32GB of ram is worth it more so if your running orthos
and not just XP11 DCS and even on the desktop >16GB fixes everything
Thank you for your advice…got G.Skill Trident Z Neo…latencies nice and low with CAS @16. Hope it works with my rig.
Quote:
“The new 3-d drawing callbacks are really only meant for custom drawing like clouds. Other techniques like adding objects to the sim and drawing markings are better handled with other APIs.”
I wonder what does it mean: “other APIs”, the only 3D drawing APis/Framework I’m aware of are: OpenGL, Direct-X, Vulkan and Metal.
In some cases I use the XPSDK instancing, but now it won’t be supported by Vulkan (I wonder why if the OpenGL bridge looks promising ?)
Could someone in Laminar elaborate on the “other APIs” ?
Thanks
Thanks
The intent here is: if you need to draw na object, use XPLMInstance. If you need to do something non-drawing, use another dataref. Etc. In other words, don’t use 3-d drawing CBs in the SDK unless you have your own proprietary 3-d drawing code.
This is maybe a stupid question, but why is rendering in Metal not supported for 3rd party plugins, there are 3d games running on Metal and X-Plane is going to running on metal and I would consider it a 3d simulator.
First, to be clear, the presence of other apps rendering on Metal and Vulkan doesn’t have any implication on whether _plugins_ should render directly in Metal and Vulkan to X-Plane’s windows. It may imply that it’s not crazy to have the sim itself render in Metal and Vulkan, but that’s not surprising – the whole point of 11.50 is that X-Plane uses these modern APIs and we’ve been saying they’re a great fit for a simulator for years now.
The question at hand is whether an add-on running as a guest inside X-Plane’s process can use these APIs to render to X-Plane’s windows, effectively sharing the Vulkan and Metal resources.
The answer is: it is not (yet) supported because we need to solve every problem of resource sharing and coordination for every shared resource to make this work, and we haven’t done that yet.
With OpenGL, most of the resources for rendering are hidden inside the GL driver, so if I give you a function call and our GL context is bound, you can just go glBegin() and boom – you’re rendering. Behind this seemingly simple mechanism is a huge amount of complexity inside the driver.
With Metal and Vulkan, most resource management is up to the app.
So there is nothing stopping a plugin from starting its own Vulkan or Metal instance, rendering to a texture, reading that texture back, and then using those bits. That can be done now. It’s not useful (because it would be very slow) but it’s possible.
But to render to our window you have to share our allocator, our render pass, our command buffer, your pipelines have to be render-pass compatible, we have to have scheduling rules for command buffers, any texture you want to use hast o be spec’d, etc. In other words, there’s a ton of internals that would need to be specified into a very complex XPLM API.
At that point if we change ANY internals, that API becomes completely broken. So at a minimum, we’re going to wait until we damn sure like our Vulkan/Metal back-ends before even thinking about how to build an API on top of them. Doing so now would be like building a house while the foundation cement hasn’t cured.
Finally, as I’ve said before, I don’t believe that Vulkan and Metal are particularly good APIs for what plugins want to do. If you have a use case where you truly believe you’re being held back by using GL and not Vulkan, ping me, and we’ll talk. But it’s worth noting that the requirements to write high performance OpenGL code (which most add-ons _do not do_) are a subset of the requirements to write _any_ Vulkan and Metal code. So a true perf problem would be one where, even after writing the high perf OpenGL, the code still isn’t fast enough.
Thanks Ben,
This explanation is vivid enough – that even non-developers grasp by now a
very deep insight beyond a hypothetical generic developer.
I enjoy much this type of elaboration. As 20 years ago, I was much fond of OpenGL on SGI, and had some wild hobby to master coding that API as being perceived the future of 3D graphics.
Its amazing how far things has developed.
Based on the recent progressions; is there any emerging estimation today about release date for xp 11.50 ?
With Vulkan how effective will having more CPU cores help performance? in VR? My current rig is i7 7700k. It seems like x2 or x3 the cores is fairly easy now days.
Waiting Vulkan so badly! I just upgraded my CPU and GPU to AMD without knowing how hard it would hit my performance with X-Plane. My 5 years old configuration is able to do 30-40 FPS. With my new AMD config I’m getting only 5-9 FPS with same graphic setting even though my new configuration much powerful than my old :S