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.

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:

• End users who are pilots
• End users who are gamers
• End users who are sim buffs
• Pro users
• Third party developers
• etc.

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.

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.

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.

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.

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.

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

_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.

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.

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.