Austin, Philipp, Alex and I presented a road map for X-Plane at FlightSimExpo this year. The official video of our talk is still not available – it’s apparently in post production. There is an audience video that does have intelligible audio, but this post provides a summary of some of the new things we presented.
X-Plane 11.25: An Artwork and Scenery Update
X-Plane 11.25 went beta during the show, and is an art-focused update. We should have a new beta out next week. Alex showed some new stuff:
- Our Las Vegas landmark scenery has a major update, building out the strip and featuring more custom buildings.
- New landmarks for downtown Chicago – the Chase building, Willis Tower, Exelon Center, Chase Tower and the cloud gate (e.g. that “bean” thing).
- Over 500 new 3-d airports from the X-Plane Scenery Gateway
- New ground marking line types for airport authors. (This wasn’t in the slides, but the lines are in there.)
New Autogen and Library
Alex also showed Petr’s new industrial autogen work, which will ship in X-Plane 11.30. The new autogen is an art upgrade that makes the existing scenery tiles with industrial areas look a lot better.
As part of his autogen work, Petr has been restructuring and organizing the scenery library, which should be a welcome improvement for gateway artists and third party developers. Over the years, the library has become disorganized and cluttered; Petr is making sure that useful art assets are in the library for reuse and are labeled in a sane way that makes them straight forward to find.
New York and Washington DC
Alex also previewed our new landmarks for New York City and Washington DC. Austin and I are particularly excited about New York City – having the real bridges modeled is going to look fantastic.
One note about the presentation: Alex incorrectly stated that NYC and DC would ship in X-Plane 11.30. They will almost certainly not ship in X-Plane 11.30. We’ve been shipping the highest profile landmark scenery packs with our smaller updates between the major patches. Since 11.30 is a major patch with a lot of code changes in it, these landmark packs will wait and go into a smaller patch.
X-Plane 11.30 and Experimental Physics
Austin showed some of the new physics tech he was working on – he has been working on prop wash and body lift forces in a lot of detail.
Blade theory does a great job of predicting how an aircraft will fly, but at its heart it is a decompositional technique – we break the aircraft into parts and then let you fly the sum of the parts. Where this becomes difficult is where there are interactions between the parts. So it’s no surprise that after almost thirty years, the area where Austin can still add better fidelity to the flight model is all in multi-part interactions:
- Prop wash – as air is accelerated through the prop, what else does it interact with? The more accurate this air mass acceleration is, the more accurate the effect on other parts of the aircraft.
- Down-wash and ground effect. When the down-wash from the wings interacts with the ground, what happens?
Austin also showed his custom test rig to measure lifting body forces. Lifting bodies work reasonably well in X-Plane now, but a better model means more accurate flight over a wider variety of regimes.
Flight Model Research Mode
X-Plane 11.30 will also introduce research mode. Research mode enables these new physics; with it disabled you get the 11.20 flight model. The basic idea is: it takes a lot of experimenting and testing to validate new physics algorithms. Until now, we’ve had to try to do this during open betas. But a beta program is relatively short (maybe 8-10 weeks) and during the beta, other parts of the simulator are broken. Aircraft authors often don’t have time to try the new physics at all, or can’t use the beta due to other bugs. As a result, we get almost no feedback during betas about flight model changes.
Research mode lets us have the next-gen physics code optionally available to everyone over a much longer time. You can think of all of 11.30 as an “open beta” of the next-gen physics. Developers who are doing real aircraft R&D can get our very best math, and authors who are trying to sort out flight model problems with Austin can use his latest tech.
Research mode is not something you set on an aircraft, it’s something you set in X-Plane. The reason for this is that research mode isn’t meant to be a stable physics model for shipping payware aircraft; it’s meant to be in-flux and evolving. We’ll make real versions out of the code that was “research mode” once we reach a point of stability.
At some point once the new physics are heavily tested, debugged, and stable, we’ll make an ‘official’ version of the flight model, and all aircraft saved in Plane-Maker will get the new physics. Aircraft saved in prior versions of X-Plane will use the compatibility code path.
Systems and Avionics
Philipp presented a number of new systems enhancements, all of which are scheduled to be part of X-Plane 11.30.
- Crew and Passenger oxygen systems.
- Anti-ice (with several different actuation mechanisms).
- Prop governors (including start locks).
- New autopilots.
One common thread of all of these new features is an increased level of real world accuracy. Philipp based this work on experience with specific real-world aircraft, and the setup for these features is based on the real world system you are simulating. Units are real world (e.g. liters of anti-ice fluid) and behaviors match real-world devices. One thing this means for third party authors: you should use these features by describing your aircraft, rather than trying to coax X-Plane into giving you an expected result.
Besides new GA autopilots (capable of accurately simulating the less sophisticated behavior that less expensive non-GPS GA planes have), the airliner autopilot has several upgrades, including full coupled auto-land. Philipp showed the 737 auto-landing under pretty serious cross-wind gusting conditions, and I can safely say that the new autopilot flies a lot better than I do.
Particle Effects System
I showed a few videos of the new particle effects system, which we are targeting to ship in X-Plane 11.30. Particle effects create smoke, fire, mist and other ephemeral effects in the sim; until recently it has not been possible to customize them.
The new particle system effects editor provides an in-app graphical editor to let authors create and customize effects in real-time. The particle effects system is entirely artist-driven; artists can make any effect and attach it anywhere on the aircraft. Effects are driven by graphical key-frame tables and datarefs (which can come from plugins). The whole system is extremely flexible.
Besides standard billboarded particles the effects system can generate “heat blur” particles that distort what is behind them and light emitting particles. The demo showed an engine fire that lit up the ground and blurred the area above it.
To answer a question that came up a lot after the show: particle effects can be attached to objects on aircraft and created by the XPLMInstancing API. We are working to allow particle effects in scenery objects, but it’s possible that will come after 11.30 ships.
Vulkan Update
I presented a progress report on our port to Vulkan. For the last year, Sidney and I have been rewriting the rendering engine to run on Vulkan and Metal as well as OpenGL. This is going to get us faster performance, reduce stuttering, and enable us to run the engine on multiple cores for better hardware utilization.
After a year of banging on the code, we’re at what is roughly perhaps a half-way point. We have several parts of the underlying code ported to Vulkan, and we can run Airfoil-Maker natively on Vulkan on Windows. While Airfoil-Maker on Vulkan isn’t useful to anyone and it’s a far cry from all of X-Plane, it’s a useful check-point for us, demonstrating that the code we’ve written so far is on the right track. It’s still too soon to say what performance will be like under Vulkan, but the Vulkan implementation of Airfoil-Maker makes 69% less driver calls than the OpenGL one; we thought that was a good sign.
We don’t have a release date or version for Vulkan other than to say that we will ship Vulkan in the v11 run and it won’t be in 11.30. We are hoping to have a beta this year, but that’s a hope, not a hard date.
To answer a question we’ve received since the talk, we are also working on a Metal port for OS X. The Vulkan and Metal port are not separate efforts; we are making a single engine that can use either graphics API as a back-end. We don’t have Airfoil-Maker running on Metal yet but I am hopeful that we get there soon.
Thank you so much for all your efforts and for keeping us apprised of exactly what is going on. This is, in my opinion, better than the videos. It appears that this is going to be a banner year for X-Plane.
Have a great Fourth of July Holiday!
Would you mind posting a copy of the slides presented? Would love to get a more ‘HD’ look at the particle system in actions.
*Bashes eyelids and holds up a bottle of scotch!*
On a really offtopic note (you don’t have to answer this)… are there any plans to update/overhaul the autogen system, particularly with the absence of AIpilotx. (My mind points to the current terrain textures/art, actual plot definitions OR have object attachments to a uv mapped texture (A similar system I believe is found in FSX, which gives ground more 3D clutter in the form of vegetation lines, etc.), and also improved coastal art (smooth and clean beachlines).
I would also implore the need for greater *in-sim* terrain editing tools (mesh/road networks/texture painting etc.) but this is probably not on the immediate agenda right now. Just hopefully ideas I can keep fresh for the next-generation of x-plane. The earlier to have these tools, the better the foundation for all of us!
Thanks for reading, and congratulations on your FSExpo presentation. Seems like you guys have everything on the right track!
Hi Dellanie,
I’ll get the slides and media up when I can – I’ve been mostly OOTO this last two weeks, so I barely got the post done a week later than I was supposed to.
Re: the AG system, we intend to continue evolving it, and the steps will be evolutionary, not revolutionary. We think we have a reasonable basic foundation (OSM data imported, processed, exported as terrain + blocks, then ‘filled in’ by X-Plane) but there’s more we can do – Petr has been doing great work on the AG art assets themselves, and with him making new assets we can do a better job of partitioning and filling out the DSFs.
Awesome to hear! Thanks for the reply!
Will the airliner autopilot updates include any work done to the auto-throttle model? Watching it over and undershoot the target cruise Mach in turbulence makes for some wonderfully silly entertainment…if the engine sound is muted ( ’cause you go crazy otherwise).
Could the particle system be an effective/efficient (or even possible) way of modeling windshield precipitation effects from inside the cockpit? E.g. rain water trajectory/pooling, etc.
There are new auto-throttle modes. I can’t say whether the tracking is improved.
Ben should stick to answering questions about graphics …
There is a new auto-throttle mode for thrust hold (N1 or EPR).
That however has no influence on speed hold, which is what you are having trouble with. X-Plane provides a controller for the speed by throttle, and it is up to the aircraft designer to set the controller up correctly, for the particular aircraft, so that it doesn’t over/undershoot too much – see https:/article/x-plane-autopilot-params/
These parameters have to be set by the airplane, because every plane will react differently.
However, in turbulence, or rather wind shear, you’d see considerable overshoot of the speed in a real plane, too. On most planes, the autothrottle is set up to react very quickly in increasing thrust in response to underspeed, and only slowly in retarding the throttles in response to overspeed. That is why in considerable shifting winds, you will see the autothrottle governed airspeed fluctuate around an average that is higher than your setpoint speed.
Very good to know! I’ve seen/heard quite a few complaints about the autothrottle behavior. I will set them straight and tell them to aviate!
And yes, I will leave that rhyme right there. Gotta take them when I can…
I run into this question with customers too. There are times when autothottle is your friend, and times when it’s not. Not the right tool for the job, that is. Sometimes, doggone it, you just have to be an aviator. 😉
HI ben.
Thanks for posting the detailed version of the FSEXPO. Is there any chance you can upload the slides and the video of the particle system. The current FSEXPO video is very bad in quality. Please upload all the slides that you used to make the presentation.
Yeah I’ll get slides and pics up soon.
Very excited about the particle effects. Will this help with improved rain windshield effects?
Ben, have you seen what the Xenviro guys are doing in terms of volumetric clouds? I am sure you have :). What is your prospective on this method and will you look into doing something like that so Xplane has this built-in by default?
Hi!
About cities with landmarks, something similar to gateway could be a good idea (and could make it more easier for you). This way, community could improve the actual cities without the liveries system.
Bye!
great news! is also tyre friction also part of 11.30 or future? Ithanks
When are your smart folks going to offer ATC?
I could not make it to the FSEXPO, where will the next FSXEPO be held. Thanks for the information.
They’ve not scheduled next year’s yet. Their site says to “stay tuned” for news about 2019.
Have you guys thought about creating bigger front yards/backyards for rural residential autogen? From up in the air it looks like a snake since autogen housing hugs the autogen roads to closely. If you guys look at Google Earth you can get some good ideas!
You guys just keep making xplane better and better. thanks for that but, are you going to make better ATC soon. thats the only thing I like better in FSX. keep up the good work guys you are great.
The future sounds promising, what steps are you taking for better ATC sounding less robotic and weather generation with realistic cloud depiction.
Forget canned ATC…use VATSIM.
Are the Q&A points in the coming Expo video, the flightsimguy didn’t record that portion, and yes there is a recording, but only from the far back of the room?
off topic… if there are problems with the v4 mesh, who do we now direct the problems too as before we all went to aipilotx. I tried emailing andras but no answers
I don’t know if the Q/A was taped by the official camera.
Re: v4 mesh, I don’t know. It’s a third party free-ware product, so there may be no support avenue now that Alpilotx has stepped back.
Hi Ben, I I know this isn’t for bug reports but I have reported this previous versions and important bug still persists.
There are no shadows or reflections when they are enabled.
Tried different scenery and aircraft but same result.
Funny thing is there is FPS cost for turning up reflections and turning on shadows yet they are not renderd.
GTX1080Ti (rolling back drivers no effect)
I really want to appreciate the graphical splendour of Xplane, it is why I purchased a 1080TI so a fix would be very welcome.
I have reported again but since nothing ever happened previously thought I would report here.
My apologies. I have finally discovered it was something deep within the rendering engine that had been changed by 3rd party program previous to its uninstall. shadows now work properly and reflections are there though not of the previous quality of Xplane 10 – they look more like flickering shadows even on max so maybe there is a driver issue or something?
Wow! Tremendous work and exciting developments coming in the future of X-Plane. Thank you to the whole Laminar team!
any projected time frame for 11.30 atm?
Hi Ben,
Will the particle effects have wing condensation and engine spool effects?
Thank you
I’m pretty sure the particle system will allow _aircraft designers_ to spew smoke, sparks, clouds or flames anytime and anywhere on an aircraft.
Its really up to the aircraft designer when to trigger any of that. But since X-plane does not model atmospheric relative humidity right now – its a bit hard to determine when such should show and when not.
In my mind, something is better than nothing. I guess authors can try to make something that feels plausible using METAR and other meteorological information like the dew point/temperature difference (spread), and maybe other information that I don’t know about.
My first plugin was even a “jab” at exactly this. If visibility was 10 km (which most of the times meant it was simply coming from the METAR), I would add a distance proportional to the spread. A lot of people liked this. It’s better than keeping the unrealistic 10 kms, just because this is the maximum value from the METAR.
Hi. Hi.
I wanted to know if it’s on the road map to improve the color of the simulator.
A color editor or some visual enhancement.
A greeting.
Love the road map and graphical improvements but one thing I have not seen mentioned is an update to the water.
I have always thought the water in Xplane is a weak link graphically as it just looks so unrealistic and bland with the texture tiles obviously repeated.
Given there is a lot of water on Earth are there any plans to improve the look of water?
+100! 🙂
+100
As a Gateway artist, I’m excited about the updated lines coming soon in 11.25B2/WED 1.7.1. I watched the Vegas video and think the updated North American industrial scenery looks great and excited we will get access to those objects. My question is related to where this new Autogen will populate. The area around the Gateway airport I have been working on (KJAX – Jacksonville, FL) is a great example. The area has a huge big box store shopping center and lots of industrial warehouses on the approach to Runway 32. Most of those have existed since well before the last scenery recut. A lot of the area is vacant or incorrectly shows up residential. Will we see any improvement to where the industrial/commercial Autogen shows up in 11.30? Will there be art assets like big box stores to help bridge the gap between downtown high-rises and suburban residential lots?
Thanks!
It depends on the zoning of the underlying DSF – that’s hard to determine from looking at the old autogen. So it might get fixed or it might require a DSF recut.
Ok, thanks. I think it is likely an issue with the source data across the area, as even the downtown area doesn’t have have tall office buildings.
You engineers keep up the good work. Meanwhile, I’ll keep watching for even better graphics and FPS. I really enjoy X-Plane – (11.20 at present). Left FSX behind in Dec 2017 and have had pretty much no regrets!!! Thanks!
Ben,
Thanks for all you do, including being the public face for all developers.
What’s the proper way to request art assets? I model mostly small airports and would really, **really**, be jazzed to see “T-Hangars”
Happy 4th.
I was hoping your scenery developments would include:
1) Left hand driving on all roads in the UK, not just the main roads
2) White line centre road markings in Europe, not yellow US style markings
3) Deletion of the light grey edges on all roads, which make them look as they have been pasted on top of the scenery
4) Ability to globally exclude autogen trees and houses, but retain rail, road and powerline networks (for use with photographic scenery).
Thanks
Item 4 already exists – we’ve had that since X-plane 8.
To the developers. Any chance that in your future updates that the rain effects can have an upgrade, and the vapor effect off the wings when taking off or landing. Just a thought. Well done guys.
I saw there’s a new version (11.25rc1) with the following update note:
“We now update the boxel scale when you drag the corner of a floating VR window.”
Could you please elaborate on that? My VR plugins still suffer from the differences between VR and non-VR with this release and I have a hard time explaining the users how to resize the windows in VR. Here’s what I observe: When resizing a window in 2D, it behaves the same no matter if I resize on an edge or the diagonal corner – the number of boxels increases, i.e. more boxels for a bigger area.
In VR, resizing a floating window using the edges also increases the number of boxels as expected. But resizing it diagonally only changes the scale – it increases the area but not the number of boxels. This is totally against my expectation. Sometimes users resize the windows to a very small size by dragging it at the side edges. This can reduce the boxel area to like 50×50. If they then make it bigger again but use the diagonal corner, the 50×50 boxels are displayed in an area of like 400×400 pixels, making everything blurry and unreadable. I can’t even detect this situation because XPLMGetWindowGeometry returns the same values (which is correct since the boxel dimensions didn’t change).
I really enjoy developing VR plugins, but this is often causing me headaches. Of course I could be misunderstanding the system, but when I reached out to the org forum, all VR developers that replied suffered from the same problem. Some of us reported it as a bug and the reply was that this is a known limitation and not a bug.
I saw now change to this in 11.25rc1 and am curious what exactly changed.
So: in VR there are two ways to make something “bigger” – you can make the window bigger to show more content (this is what bigger means in the 2-d world) or you can make the whole window bigger in VR space while showing the same content – sort of a ‘zoom’. This second operation (scaling up the content) is the equivalent of picking 150% UI size, lowering x-plane’s resolution or buying a bigger monitor.
It matters because in the 2-d world with monitors, your distance to all points on your monitor is about the same, so the UI size set to all of X-Plane is fine.
in VR, your plugin windows might be all over the cockpit, so it’s useful to make some be “large print”.
In our UI, the corner drag scales, the edge drags resize. This is true for both plugin and non-plugin windows.
Now…this UI is astonishing to nearly everyone, including Tyler, who constantly reminds Chris and I that it is totally astonishing and a constant source of confusion. So we may change this UI in the future. If/when we do, your pluign windows behavior will change so that they continue to match the non-plugin windows that look exactly the same – the goal here is _consistency_ of the entire UI, rather than having each window have its own behavior.
With that in mind, the bug fix is: before 11.25r1, if the user resized the corner of the window (scaling up the content) and then the plugin changed the window’s size (to show more content) the scaling would be undone. This is fixed – the user’s scale is preserved even when your plugin grows the window to show more content.
So this is where I’m confused a little bit. Since Vulkan and Metal are two completely different APIs, is it just the application that needs to be adapted to these new APIs? Because I don’t understand how the same addons such as aircraft, scenery, or plugins could run on both Vulkan and Metal at the same time.
_IF_ we support a “native” drawing API for 3-d under Vulkan and Metal (OpenGL drawing in 3-d won’t work under Vulkan or Metal) then those add-ons will have to be rewritten once for each API. (This does not apply to add-ons that “draw” 3-d OBJ files because that drawing can be totally outsourced to x-plane, which will already be Vulkan and Metal native.
For 2-d drawing, the add-on draws in OpenGL and we composite the OpenGL drawing on top of the metal drawing, so no rewrite.
Hi Ben!
When I see “_IF_” in that context, I get the willies as a developer. 😉 Clearly you wouldn’t have written that first paragraph if add-ons that draw in 3D did not exist under OpenGL X-Plane. Is that a reasonable deduction?
We’ve seen some major advances – even as far back as X-Plane 10.30 – where support via the SDK has begun to lag. After one conversation I had at FSExpo with Philipp, I am starting to sense LR backing away from having a robust SDK that interacts with the most recent and highly desirable features of the sim. I hope that perception is more observation on my part than a real intention on LR’s part.
One big, ginormous reason that the 3rd party market for X-Plane is as viable as it is would be due to the SDK. If it isn’t kept up to date with new tech in the sim, that’s going to be a greater and greater issue for the 3rd party add-on world as time marches on.
I can see that as X-Plane starts to improve geometrically – especially with an ever increasing staff – the areas in which the SDK could potentially stick it’s needy little fingers can start to increase geometrically as well. No question that’s a bear.
Updating the SDK is hard, and no doubt can produce failures and uncertainties all its own. Philipp mentioned issues that LR encountered during the introduction of VR, which resulted in the decision to not update XPLMNavigation during the XP11 run. Please don’t let hard == NO.
If I’m totally off base here, misinformed or otherwise tilting at a windmill, my apologies!
When you and Sandy Barbour created the SDK in the first place, times were much simpler (as if the SDK could ever be thought of that way). I also realize that it was largely a volunteer effort on Sandy’s part. However, what has evolved is perhaps the most phenomenal and straightforward means of extending an application that exists in all of flight sim, and the development ecosystem that is currently thriving can only get larger and more robust as time marches on — as long as the SDK is kept current.
Is there anything that you would say in response to reassure, or to refute if necessary? I would really like to understand the depth and breadth of Laminar Research’s intentions for the future of the X-Plane SDK. I doubt I’m alone.
As someone that has made his living for a time using the X-Plane SDK and writing add-ons, I can tell you that this is one of the single coolest and most valuable personal experiences I’ve ever had, as well as the relationships that I’ve formed with you, Philipp, Austin and the rest of the staff. There is a thing you’ve referred to as the SDK “glue” that links SDK functions to X-Plane. I see the SDK itself as the glue that links LR to the third party ecosystem. Both wonderful things.
Thanks for all of your efforts. It’s truly an amazing sim, and going amazing places.
Steve
Hi Steve,
To clarify the record, when Sandy and I made the X-Plane SDK, _I_ was a volunteer too, and the original SDK effort was _entirely_ a volunteer effort. Our agreement with Austin was basically to “not break the sim”. Austin didn’t have any interest in doing a C API himself (and he considered UDP just fine) but he was always (and still is) libertarian about letting other people do what they wanted.
I think the SDK was clearly wildly successful in that we wouldn’t be having any of these suggestions if the main take-away was that people weren’t using it.
With that in mind, I don’t think Sandy and I had any strong comprehension of the compatibility consequences of the APIs we exposed. While we wanted them to be long lasting and were generally aware of compatibility issues that growing APIs and sub-systems could have, we had no specific flight sim domain experience. To make things worse, the actual state of backward compatibility in X-Plane was insanely low at the time*, which I think made us less concerned about longevity…basically we would have been over-engineering the job relative to what volunteers could do in a way appropriate for X-Plane 6 if we’d sweated the issues biting us now.
In that context, there is _no_ reason to think that because “X” is or was a feature in the SDK in the past that “X” is a good idea that should be in the SDK in the future. It might be that feature X was a dumb idea, wasn’t well thought through, turned out to be an API that was brittle, or is an abstraction that just no longer works. There really isn’t automatic grandfathering for whether a design idea is a good one.
So 3-d drawing is definitely one that we need to rethink and not just automatically renew with new graphics APIs. 3-d drawing as an SDK feature has worked less and less well as the rendering engine has become more sophisticated, to the point of being a nearly unusable feature in 11.x. It’s likely the restrictions on add-ons will be even worse and compatibility harder to maintain with new APIs. That doesn’ mean it’s definitely NOT happening, just that there are strong strikes against it. We’re listening to third party developers and considering things, and a final decision hasn’t been made.
In general I would say our reluctance to do new SDK/API features is based on a desire to have them work correctly up-front and not be half-baked, broken, unusable, or unmaintainable. This is a case where trying to do SDK features cheaply by ignoring the details of the API, error checking, testing, and documentation results in an endless stream of maintenance work down the road that takes time away from doing future API features. I totally get that this slow pace of exposed features is frustrating to third parties – I was once in that exact position.
But I think it’s important to remember that what seems like a ‘wide’ past API isn’t nearly as comprehensive as it looks due to bugs, limitations, abstractions that don’t fit, etc.
* Recall that from v5 to v6 the panel size changed, breaking all panels, the instruments were repainted, the ENV grid size changed (no backward compatibility), and the paint scheme was atlased. My very first add-on, “XPaintConverter” was an upgrade tool to atlas v5 paint jobs into v6 versions, because I got annoyed at finding all of my favorite aircraft available only n v5 and not v6 format. It was the wild west.
Ben – Thanks for that. Perhaps this was an opportunity to let loose some thinking that’s been in the background for a while, and it really makes sense – even if in some ways also disappointing to those of us eager to use new SDK features.
I couldn’t agree more – don’t break the sim, and don’t do wild and crazy new things hastily if they could make for more work down the road needlessly. A lesson for all dev’s to take heed, I would think.
I really appreciate the time you took to write that, as your time is quite valuable. It could make for a long blog post all its own.
Of course, this again brings to mind the 2D vs 3D nature of the rather popular means of scripting graphical elements using 1-sim’s SASL product. Right now we can use SASL’s ability to draw on the 2D panel.png texture to add new instrumentation to the 3D cockpit. It sounds like that’s going away when one uses the Vulkan/Metal version of the sim.
This begs a question: just like one must choose which X-Plane 10 to use, 32 or 64 bit, it sounds like we’re going to have to choose which graphics API we use when we start X-Plane 11 in the future. Is this correct?
SASL is also useful for creating 2D overlays that are not drawn on 3D models – they’re just *there.*
I think it’s very important for aircraft developers to know what’s really still going to work as we go into Vulkan/Metal. I’ve been getting ready to do a really nice new 3D FMS display using SASL, so I’m especially concerned, and want to be sure to avoid stepping “in it.”
You’ve said that 2D should “just work.” That’s encouraging for 2D SASL.
However, it sounds like anything that writes to the panel texture is using OpenGL calls that will break under Vulkan. It also sounds like this would be directly affected by whether or not a new native drawing API is produced.
If my fears are incorrect and this is still going to work with certainty, it would be good to know. If not, there’s a cliff that it would be good to avoid driving off of in terms of wasted development time and angry user/customers.
We discussed this briefly at FSExpo, and I appreciate what you shared then.
I know that there will be OpenGL support through the end of X-Plane 11. But I think it fair to worry that this won’t be the case in X-Plane 12. We know it’s out there, over the horizon, and it only makes sense to want our products to be viable through as many X-Plane iterations as possible.
Given that one will have to choose which variant of X-Plane 11 to use – OpenGL or Vulkan or Metal – it’s also important to have a product that works across all three.
Let me be totally clear about this, because your fundamental assumption here is wrong (but the confusion is pretty understandable).
– When you draw on top of the 2-d panel (in 2-d) using a 2-d drawing callback, and then, later, X-plane uses that as a texture to draw the 3-d cockpit, this counts as __2-D drawing__ for the purpose of plugin, support, _not_ 3-d drawing.
– Therefore, the intended legacy support for 2-d drawing via OpenGL even during Vulkan includes custom avionics in SASL where the results are part of the panel _texture_.
– Note that there _is_ no way to draw in 3-d _inside_ the 3-d cockpit at all, so there’s no loss of support of this.
Here’s the underlying issue: we don’t have a reliable way to share the entire 3-d environment (depth buffer, etc.) across drawing modes; we can make the 2-d drawing work because we can take the _end results_ of the 2-d drawing and composite it as a texture on top of the rendering from another API. The panel fits this model.
One thing I’d like to add to what Ben said: as a small team, we have to be extremely strategic about how we spend our time—we have to say “no” waaaaaaay more than we get to say “yes,” because there’s only so much engineering power and so many, many things we’d like to do. (Even big companies like Microsoft aren’t immune to having limited resources—MS has been talking about sets for something like a year, and they just pulled it from the next release… again!)
During the quarterly planning meetings, we always wind up with a giant whiteboard full of things we’d like to do, but we have to choose maybe a handful of big things that we actually can do. And those choices have to balance the needs of a lot of competing groups who disagree on what’s most important… We’ve got:
So while it’s never the case that something being time consuming automatically excludes it from consideration (rewriting the UI from scratch for V11 definitely falls in the time consuming category), it is often the case that the payoff for the community is lower relative to the other stuff we could be working on.
Great, we can expect a lot more.
X-Plane is getting better and better.
But I have a question or request:
Is it planned to adjust the weather so that not every time the weather is updated, the sky is completely cleaned and then the new clouds are drawn…?
In my opinion, that is not really realistic.
Otherwise, you’re on the right track.
Very thrilled, in particular about Austin changing his mind about the physics engine! 🙂