X-Plane has always shipped with the shaders visible to everyone as plain text in the Resources/shader directory. Partly this was due to making it convenient to load the shaders into OpenGL itself, but we also don’t have anything to hide there either so it doesn’t make much sense to try to hide them. You are more than welcome to look and poke at our shaders and if you learn something about X-Plane in the process, that’s awesome!
However, the one big caveat to that is that we never considered the shaders to be part of the publicly accessible interface and they are in no way stable across versions. X-Plane is an actively developed product and we are making a lot of changes to the codebase, including the shaders, so you should never ever distribute a plugin or tool that modifies the shaders. Since we give no guarantee that our shaders will remain stable across versions, you’ll always be left worrying that we might break your add-on.
Additionally, there is a big change to the shader system coming in 11.30 that will definitely break all existing plugins that are modifying shaders. This blog post will cover the upcoming changes and hopefully convince everyone that the shader system is in flux and not to be relied upon as a basis for add-ons.
Just to make one thing clear though, the changes discussed here will only affect a very small number of add-ons! If you have no idea what this post is about you are not affected. If you do custom drawing for panels or GUI or even 3D and are either using your own shaders or never touch the OpenGL shader state, you are also good! If you have been using our shaders for custom drawing, now is the time to switch to the new XPLMInstance API that has been available since 11.10. This is a general piece advice for anyone doing custom 3D drawing in OpenGL because that will not be supported in Vulkan or Metal without changes, whereas the XPLM API will continue to work. If you are doing 2D GUI or panel rendering using OpenGL, we’ll make this transparently work in the new Vulkan and Metal world.
With all of that out of the way, let’s dive straight in.
The Current Shader System
Currently the shader system relies on runtime specialization, meaning we have all variations of our shaders in a single shader file. We then compute the options we want based on the attributes we discover at runtime and based on that pick the right variation. For a simplified example, consider this
vec4 pick_color()
{
#if HALF_TRANSPARENT
float alpha = 0.5;
#else
float alpha = 1.0;
#endif
#if WANT_GREEN
return vec4(0, 1, 0, alpha);
#else
return vec4(1, 0, 0, alpha);
#endif
}
There’s two specializations, HALF_TRANSPARENT and WANT_GREEN. When loading shaders, X-Plane injects the appropriate #define‘s into the shader code so that the driver will compile the version of the shader that we want. This makes it very easy to work with the shaders and modifying the master shader will modify all of the hundreds of specialized shaders that will be compiled from it at runtime.
If you have ever worked with shaders beyond just drawing a simple cube or hello world triangle, you’ll be aware of this concept of ubershader. The long story short is that historically GPUs have been very bad at dynamic branching and have always preferred execution with as little control flow as possible. This is why it’s just not feasible to have all of these options dynamically evaluated when the shader is executed and instead the code is written in such a way that each options gets compiled into its own shader. This concept is neither new nor is it terribly exciting, however, X-Plane is departing from this classical design in favor of a Vulkan friendly and modern shader system.
The Glorious Future Shader System
In the future we are planning to switch to Vulkan and Metal for our rendering needs. We also want to continue to provide OpenGL support for X-Plane 11 on top of that. Both Vulkan and Metal have their own respective binary shader format and can’t load GLSL directly. (Vulkan in theory can with the right vendor extension, but it’s not vanilla GLSL.) We currently support 3 versions of GLSL; 1.20 for macOS, 1.30 and 1.50. That means we need 5 different versions of each shader. On top of that, Vulkan and Metal no longer allow the same kinds of runtime specializations that GLSL allowed and instead want shaders to be pre-compiled offline through their respective shader compilers.
We thought long and hard about this shader problem, because we suddenly were faced with the possibility of having to maintain 5 versions of the same shader for our different rendering backends, as well as having to figure out how we want to ship all of that. Theoretically we could ship the shader compilers with X-Plane itself and still compile the shader at runtime, but that comes with a huge performance penalty attached. Since our whole goal with the move to Vulkan and Metal is to improve performance, we decided to pre-compile our shaders offline instead. That means that at build time we will compile every single version of our shaders and save them to disk. Then at runtime X-Plane will load these shaders and not touch them any further. This means that when we write a single shader we can easily end up with 3000+ specialized shader files on disk! This is an actual thing; one of our heaviest master shader generates 3780 shader files per target (i.e. GLSL 1.20, 1.30, 1.50, Vulkan and Metal).
The other thing we decided on was to use Vulkan’s shader format, SPIR-V, as our new intermediate shader format and then transpile our required GLSL and Metal shaders from that. That way we can have a single master shader file that gets compiled into all the required SPIR-V binaries and from there on then gets transpiled. SPIR-V is designed as an intermediate format anyways, so it seemed like good fit for our needs. Because SPIR-V is an IR, we can also run optimizers over it and optimize our shaders offline, already giving us a nice baseline to work with.
This means that if you relied on modifying a single shader file created by humans with human consumption in mind, you will now suddenly be faced with thousands of automatically transpiled shaders that are definitely not good for human consumption. Because the compiler is stripping out all dead code and then applying optimizing transformations on top, you will have no idea what file corresponds to which specialization and what input lead to it. Plus, the shaders are even more volatile than before, because we can easily run new optimization passes at any time and ship completely different shaders, without even having to change a single piece of the master shader file
Here is a concrete example of such a transpiled shader:
Original:
void main()
{
STD_BROADCAST
gl_Position = u_mvp_matrix * (vec4(a_vertex, 0, 1) - vec4(u_mv_offset,0.0));
v_texcoord0 = a_texcoord0;
v_color = vec4(to_linear(a_color.rgb), a_color.a);
#if BORDER
v_texcoord1 = vec4(to_linear(a_texcoord1.rgb),a_texcoord1.a);
#endif
}
One transpiled version:
void main()
{
gl_Position = mvp_matrix * (vec4(a_vertex, 0.0, 1.0) - vec4(u_mv_offset, 0.0));
v_texcoord0 = a_texcoord0;
vec3 param = vec4(u_imm_a_color).xyz;
v_color = vec4(to_linear(param), vec4(u_imm_a_color).w);
}
Another
void main():
{
gl_ViewportIndex = gl_InstanceID % u_viewport_count;
gl_Layer = gl_InstanceID % u_layer_count;
gl_Position = mvp_matrix[gl_InstanceID % u_transform_count] * (vec4(a_vertex, 0.0, 1.0) - vec4(u_mv_offset, 0.0));
v_texcoord0 = a_texcoord0;
vec3 param = vec4(u_imm_a_color).xyz;
v_color = vec4(to_linear(param), vec4(u_imm_a_color).w);
}
Note that neither version actually had the BORDER specialization set. The difference in this case came from the fact that STD_BROADCAST expanded into two different versions.
Here is another example of code that got so mangled that it’ll be really hard to figure out what’s going on without access to the master shaders that we use to compile these from:
bool _17541 = u_normal_mode != 6;
bool _22009;
if (_17541)
{
_22009 = u_normal_mode != 3;
}
else
{
_22009 = _17541;
}
if (_22009)
{
per_pixel_normal.z = 0.039999999105930328369140625;
}
Would you know what the magic values 6 and 3 are? Besides that, the compiler is also making up a bunch of intermediate variables with auto generated names.
Those examples came from the transpiled GLSL shaders. Do you actually want to go through SPIR-V disassembly and patch that?
Summary
The quick summary is: Don’t touch our shaders, mkay?
Since they are not part of the public X-Plane API, we’ll mercilessly change them when necessary. You might have been able to get away with it up until now, but the shaders will become much much more volatile! Especially because they are written by a computer without any emotions, the number of shaders as well as the content can change at any time, without us having to touch the shaders at all. We might decide to upgrade to a newer version of the underlying compiler toolchain and suddenly the shaders are completely reorganized. This isn’t just something theoretical; while developing our shader compiler toolchain I’ve gone through multiple versions of the SPIR-V compiler and each one of them changed the generated shaders in some way (usually it got more obfuscated but at the same time also faster).
If you want to change our shaders, you are still very welcome to do so! You are also very welcome to just look at them if you feel up for it. Just please don’t try to make a product out of modifying the shaders, because you’ll be fighting some really strong headwinds.
Hello Sydney,
Many thanks for detailed explanation of The Glorious Future Shader System.
It looks like exciting series 🙂
Season 1. “Art Controls Are An Active Volcano”, 2014. (//developer.x-plane.com/2014/05/art-controls-are-an-active-volcano/)
Season 2. “Our shaders don’t like to be touched”, 2018.
I, as an admirer of X-Plane, switched from another sim after XP 11, just can’t understand why such capabilites as private datarefs/shaders alterations carefully blocked?
With these alterations X-Plane shines in all its splendour and de facto almost all users are using them by using incredible addons developed by community.
I hope that future releases of X-Plane will provide interfaces for visual tuning and utilize full advantage of the flexibility of sim.
Without next season of this series and ignoring letters from developers.
On this occasion could you please answer a couple of questions:
– The article is entitiled “Our shaders don’t like to be touched”. But in the final paragraph you wrote: “If you want to change our shaders, you are still very welcome to do so!”. I see a conflict here. You mean I can change shaders, but use it personally? Or just look at changed source code? Or it means I can share my work with community only as freeware?
– When I wrote my plugin for X-Plane-11 via SDK, I found that XPLMFindDataRef() function returns null for /sim/private/* datarefs, as described at Season 1. “Art Controls Are An Active Volcano”.
But I know a plenty of plugins, even _payware_, which are changing private datarefs. How they do it? SDK documentation seems vague on details.
Thanks.
Hi Yuri!
I can’t promise a sanctioned way to modify shaders in the future, the problem being that we are moving to shaders compiled offline at X-Plane’s build time. That’s not to say it will never happen, but it’s not anything that’s on our roadmap right now.
I’ll try to answer your question about us blocking access to our shaders and the conflict between the title and my last paragraph in one go: We are not trying to take access away or forbid anyone from seeing and interacting with their sim as they see fit. If we wanted to, it’d be easy to never show art controls or hide the shader in an obfuscated blob. That’s not our intention, in fact, we welcome anyone who wants to dig into the sim and play around with art controls and the shaders. If you learn something about X-Plane in the process, that’s awesome! We are trying to be pretty open about things and where the bodies are buried.
With the shader system changes coming up, you are still very welcome to look at the shaders and change them. What I was trying to say is that you shouldn’t build a product out of it, because the interface is inherently unstable. You will get users that are unhappy when the art control you relied on, or the shader you modified, gets cut. And that’s what I’m trying to stress here; we give no guarantee that the things that are not part of the publicly documented interface will continue to exist across versions, or even do the same that they did before.
Now, historically the shaders did change at a very low frequency, but this is bound to change due to the fact that they are offline compiled and we can enable new compiler optimizations at any point which will change the shaders. If you create a product that modifies these shaders, chances are that you will have to completely relearn them between versions. Not to mention that we no longer ship a single shader but thousands of shaders, that you all need to learn. If you really really really really really want to build a product out of that, I can’t stop you, but at least I tried to stop you from unnecessary pain. If it breaks left right and center, I don’t want to hear about it afterwards.
Regarding why XPLMFindDataRef doesn’t return art controls, you can get them with the “sim/private/” prefix (note that there is no leading backslash).
Of course, you ARE actively putting up a barrier to Yuri’s product by removing the shader source files (for humans) and only including the generated files.
If you choose to still include the [human] source files you’d open up the choice.
Yep, I know the runtime doesnt NEED the source, but I presume Yuri’s product could choose to generated the 7000 shaders?
You would totally have a point if we suddenly pulled the rug under developers feet away, but the reality is that we have always maintained the position that our shaders are not part of the public SDK. If I keep going around and tell you that the stove is hot and if you touch it you’ll hurt yourself, I’m not actively harming you if you then proceed to touch the hot stove.
There is a bit more to it than “just” generating thousands of files, so even if we still included the original master shaders, that wouldn’t do him much good. Plus, even if we did, we would be back at square one: If we implemented new shader tricks or optimized things, are we actively putting a barrier on other developers products again? We can’t just never ship new shaders ever again, that’s just not feasible.
Well, I’d stick to the simple ‘we will be changing our shaders, so play with them at your own risk’.
If you give a reason, you,invite annoying people like me to poke holes in the logic.
Anyway! How about nvidia RTX 2080 as a good reason to assume the shader system will change… 🙂
Also, good post please keep posting.
Thanks for making it clear, Sidney.
Regarding second question: whan I wrote “returns null for /sim/private/* datarefs” I didn’t using a strong syntax, just describe a common situation.
To be more precise: here is a fragment of my code (Delphi syntax)
——————–
…
TXVDataRefs = record
FName: PAnsiChar;
FDataRef: XPLMDataRef;
FValue : Single;
end;
…
…
XVDataRefs : array [1..MaxDataref] of TXVDataRefs = (
(FName:’sim/flightmodel/controls/wing1l_elv1def’; FDataRef: nil; FValue: 0.0),
(FName:’sim/private/controls/clouds/light_curve_power’; FDataRef: nil; FValue: 0.0),
(FName:’sim/private/controls/clouds/spec_gain’; FDataRef: nil; FValue: 0.0),
(FName:’sim/private/controls/clouds/ambient_gain’; FDataRef: nil; FValue: 0.0),
(FName:’sim/private/controls/clouds/diffuse_gain’; FDataRef: nil; FValue: 0.0)
);
….
procedure Initialize;
var
I : Integer;
begin
Log(‘Initialize’);
for I := 1 to MaxDataRef do
XVDataRefs[I].FDataRef := XPLMFindDataRef(XVDataRefs[I].FName);
end;
——————–
I found that for I = 1 (‘sim/flightmodel/controls/wing1l_elv1def’ dataref) SDK function XPLMFindDataRef() returns a valid pointer to dataref, but for other elements of the array XPLMFindDataRef() returns NIL.
I’ve tested for some other datarefs and found that if I address private datarefs (‘sim/private/*’), function returns NIL, while for other, not private, returns a valid pointer.
So, if ‘sim/private/*’ is an active volcano, how other plugins, including _payware_, access them? Are they pure hacks or a gap in SDK documentation?
The other art controls aren’t actually art controls and don’t exist. X-Plane will return pointer to art controls via XPLMFindDataRef(), but only if they actually exist. DRE can show you which art controls actually exist or not, at least in your specific version, but those art controls are subject to change and might also be gone at some point!
I wouldn’t exactly call this a gap in the documentation, art controls are not documented at all. They are private, and if you want to discover them and figure out what they do, that’s on you. They are not part of the public SDK at all, hence why we don’t document them.
Hi guys, I realize that the more technically savvy among us know what’s going on here and what you’re talking about. But could you post a little explanation to those uninitiated and graphics as to exactly what a “shader” is ? You’d be surprised how many people ask me “what are they talking about”? And I don’t quite know how to answer it. So perhaps a little lexicon of terminologies should be put forth for the “graphically challenged” LOL.
Thanks
There’s this magical thing called Google that will answer your question a thousandfold. Be resourceful, man!
Basically he is saying don’t make addons, program or plugins, that change or tweak the shaders.
You can make an addons or plugin and play with the shaders you are free to do that BUT don’t complain when your addon breaks because x-plane dev team changed the shaders code suddenly, because you will have to change your addon code every time they do.
For us end users it mean programs like Xvision will not work on 11.30, unless the author update his program to work with the new shaders.
//en.wikipedia.org/wiki/Shader
> Additionally, there is a big change to the shader system coming in 11.30 that will definitely break all existing plugins that are modifying shaders.
There is this new product “X-Vision” which among other things fixes the weird blue scattering effect below the horizon at dawn/dusk (which is out of place as above the horizon the sky is yellow/orange).
Speaking as end-user and not as a developer I sincerely hope you fix that glitch before the compatibility break 🙂 thanks!!
And BTW, do the new shader system come with updated shaders or they do more or less the same as the current ones? By updated I mean some new effects or fixes.
Thanks!
Of course! It’s not actually important to understand this post though, if it’s a bunch of techno babble, then it’s not something that will affect you! The intended target audience of this post is definitely the 5 people who know about shaders and know at least theoretically how a modern graphics stack is build up, but I can give a quick summary about what a shader is. Just real quick though, the changes talked about in this post are only about the way we bundle our shaders with X-Plane itself. The way X-Plane itself draws will not change! So we have an all new and better shader delivery system, but the end result on your screen will look exactly the same!
Skipping the whole history as well as glancing over a lot of small details, the long story short is that shaders are small programs that run on the GPU. These programs are responsible for actually rendering any pixels to the screen. The GPU will invoke one kind of shader, the pixel shader, once for every pixel that is drawn. The pixel shader then computes the colour of that one pixel and outputs it into the framebuffer which is eventually flushed onto the screen. GPUs have a huge amount of shader units which run in parallel, each running one instance of the pixel shader and computing a single pixel in the framebuffer. Because shaders make the GPU programmable, they are an incredibly powerful tool to have. Before shaders came to be, the GPU had a few hardwired functions it could do, but with shaders you can draw just about anything. Take PBR for example, at it’s core, it calculates the direction of the surface it’s drawing and also reads out the base colour from the model texture. Then it looks up how shiny the surface is, samples the environment to figure out what colour it’s emitting and mixes all three together to arrive at the final pixel colour. All of these steps are just a few hundred lines of shader code, and because the programmer has control over the code that the GPU is executing, the whole process can be tweaked so that the end result looks perfect.
Basically to render a something on the screen, the CPU will execute some code that generates commands for the GPU. One of those commands is a draw command which tells the GPU to execute some piece of code and feed it certain input data. The GPU will then execute that code with the specified input parameters and the code will output the pixel. And that GPU code, that’s what’s called shaders.
I hope that clears things up. It’s a complex topic that’s a bit hard to explain without going on extremely long and boring tangents.
If I understand well, the source, human written shaders will not be available anymore.
I see a big problem for developers: the shaders’s comments explain some parameters that are not available in the vastly incomplete scenery documentation. And if not, the clearly written code allows some findings.
For example, nothing in the doc gives any hint that the tiling shader can work with 2 textures at once as source for albedo in the same .ter.
I can give a lot of examples.
Of course, the proper solution would be to complete the documentation, including all the obscure parameters which existence is only revealed by reading the default scenery’s terrain files (I tried once to reverse engineer the many undocumented parameters for composite texture just by trial and errors… no way !).
All the best,
Pascal
Exactly. The fix here is to fix the docs, which everyone can read, as opposed to the shaders, which only programmers can read.
Just want to say thank you for removing the option to tinker with the shaders. Also to hopefully put an end to reshade usage and programs alike. A native shader support that is only maintained by you guys are the best way to secure a stable platform. Hacking through art controls through lua scripts and programs that run them, these all are ways to make the program “pretty” as per definition by the eye of the beholder. But for the general users both new and old, I do feel X-Plane needs to uphold a restrictive but open attitude towards tinkering and eyecandy hacking. Reason being the simulator needs to perform, not just look good. So let’s make X-Plane great again, and for that I wanted to say my gratitude.
Totally disagree with you. Its an option for many. No one is forcing you to use these programs. X vision has changed the sim for so many in a positive way. Maybe if LM took a leaf out of x visions book, there would be no need for such programs. I do agree that programs like reshade should not be used, but x vision is a good example of what can be achieved when done correctly. I’m not X plane bashing as I love the sim and what it has brought to the sim community.
I never thought I would read something like this. You are thanking LR for reducing the options we have to customize/adapt the sim to our liking!?
But with this I’m not saying I disapprove of what LR is doing. If compiling shaders at build time is necessary and benefitial for us, so be it. But if LR could easily include sourcecode that would help developers in creating products, proactively and knowingly not doing this because “shaders don’t like to be touched” doesn’t seem logical to me….
I totally disagree with the first comment. Customization is always good. If you don’t want to do it, fine. But let others do. What would you say if the government would come to your house and repaint all your walls grey (because that is the official government color), and they wouldn’t allow you to change it. Asking for less customization is -sorry to say – is selfish and dumb. Your sim’s stability won’t be affected by others using Reshade at their home computer.
X-plane’s colors are very washed out by default. There is also no bloom, etc. We all like in a different way. To me it was imperative to use Reshade as soon as I got involved with X-plane. Just take a look at the colors of Aerofly FS2, and you’ll understand in a heartbeat. And it’s quite possible that this option will be taken away from me very soon. Does that make you happy?
Hi Peter,
I gotta say, I think the analogy between the government painting your house grey and software being customizable is a really tenuous analogy, and risks derailing the thread.
We can have a conversation about the trade-offs between flexibility, reliability, ease of use, stability and ease of development. (I’d rather not because the issue of how many settings x-plane gives you access to has been beaten to death in this blog already.) But these issues are entirely ones of _trade-offs_ and there’s no free win. It’s reasonable for you to say “I want more flexibility, I value it as a feature”, but it’s reasonable for other users to say “I don’t value flexibility, and I don’t want to see it take up resources (e.g. in the form of it becoming yet another engineering goal in a zero sum game.)” That’s not quite the same as “some entity used its power/authority to take away your civil liberties.”
Xvision has changed the sim for so many in a positive way!! Iam sad that i reed this so late a short time ago i bought the Flight Factor A320 now i am Angry that i wasted more Money for a Game that is going back and not Forward. Only the Community Add ons are usefull and make that the Sim Looks realy great. The normal Xplane Looks soo bad. If u compare with Reshade and XVision makes the great. If this changes are comming and there is not alternative way that works better or at the same way i have to buy P3D because i want a usefull and GREAT LOKKING FLIGHT SIM not Graphics like FS 2002 first the Communty Addons make Xplane playable and usefull not the Standrad Sim. Greetings from Germany Bye
This comment isn’t really constructive. The new shaders are a stepping stone to a future X-Plane with a lower overhead (which in turn can be used to make the sim look and feel better.)
What does all this mean to an end user like me who for instance bought the plug – in Xenviro 15 months ago? I’m asking here cause the team behind xenviro is very unclear with the reason why their plug in is so unstable apart from blaming LR for messing around with the base code all the time. (that’s a quote).
This change only affects plugins that rely on our shaders. I’ve talked to Andrey about this, and xEnviro will not be affected since he uses his own shaders for drawing. A prominent plugin that is affected though is xvision, which is from a different developer and is explicitly built to modify the shaders.
Thanks Sidney. So if I understand correctly you wouldn’t from an end users point of view be to concerned the way Xenviro goes vs. LRs policies on shaders etc..
There’s no LRs policies on shaders….. they said it all around. Shaders will change more frequently and they will be more of them. If someone (developer that do what he shouldn’t [modifying what it should not]) do modify them, it’s his/her/their problem. It’s very clear why some people don’t want to understand.
Wouldn’t it be possible to open up some rendering options to developers in the future? I am a big fan of the X-Vision tool as it greatly improves some visual aspects in my opinion. The key improvements it makes for me are:
– Post processing to add more color and contrast (primarily the curves effect)
– Wider and brighter sun glitter
– Brighter emissive textures at night (makes night flying even beter, especially in VR)
– Changing the sunlight color to a warmer tint
– Changing the night spot lights through the lights.txt (makes night flying even beter, especially in VR)
A lot of these changes are probably very personal, though the ‘Impressive’ solution from X-Vision was almost spot-on for me, so I guess a lot more people love the same improvements. It brought some of the things I loved in Aerofly FS2 to X-Plane like the better contrast and warmer sunlight, making X-Plane an even better sim. I’m actually a bit scared to what 11.30 will bring as we probably have to go back to the lower contrast, colder sunlight and darker nights. X-Plane by default just feels a bit flat in color and contrast to me.
Wouldn’t it be possible to expose some documented variables like the sunlight color, emissive texture components, sunlight glitter and so on through the plugin SDK so these can be tweaked? And maybe it would be possible for you to add some control over the output image to the default X-Plane (brightness, contrast, color saturation)? Or maybe it is possible to open up some steps in the shader process to developers by adding some empty documented shaders that can be modified to allow things like post-processing directly on the shader level?
I really hope that there are some possibilities here, so that the great work the X-Vision team did won’t be for nothing.
Right .. this is a form of “why isn’t tweak X part of an SDK” where X is a plugin post-processing option, an art control, or even editing shaders.
The short version is that making X an SDK item (which to us means: we will really try hard to make sure that an add-on using X _keeps working_ for the entire version run) is not free. Here are all of the costs:
1. It requires us to NEVER change the sub-system that presents X for the life of the version. Here’s an example: right now X-Plane draws a sky dome (a big hemisphere around your camera painted blue). If we make “customize the skydome” into an SDK item (so that plugins can be like “no, we draw the sky-dome”, we can’t ever change how the skydome is drawn. We can’t change it to use more than one layer drawn at different times, we can’t change to a procedural approach, we can’t change it to some kind of volumetric ray tracing API. We’re stuck with the _overall approach_ (paint a sphere) that we had at the time of the API.
Now that might be okay! We’ve had a sky dome for a VERY long time and we don’t have short term plans to change that. But the lock-in is still there…making feature X be in the court of third parties means it is off limits to us.
2. It requires us to re-test third party add-ons any time code NEAR feature X is changed. This takes time every time we do a release, because we have to test the interactions of one module against several others, none of which are ours. If an interaction bug happens, we have to fix it in one half of the two modules – the one we control. This is all slower and more awkward.
3. It requires us to document the interface in a clear way. This doesn’t happen for free either.
When a feature is small (“this one art control”) the cost of docs is very small, but the cost of not changing it can be very high, since a single art control is not an entire component in x-plane, it’s one tiny aspect of one component. When a feature is big (“you own all rendering of X”) then the cost of docs and building the interface is very high, but at least the module really is a module (albeit one that might have a huge impact on the architecture of the sim).
In general, a lot of the changes being made by these add-ons are totally based on “tweaking our implementation”, and thus have _no_ logical way to become an SDK. Making our implementation into an SDK means supporting a bizarre non-flexible SDK that will only support tweaking and leave everyone stuck on current-gen technology forever.
Ok, I see the dilemma there. Thanks for taking the time to reply to this in so much detail. I was just hoping for a way to make what X-Vision did possible in future versions in a more constructive way. That tool (for me) made the final small nudge in combination with the great VR implementation from 11.20 so that X-Plane actually looks real at many times.
Back in the days of MSFS4 and earlier we probably all dreamed about a photo realistic VR flight simulator, these simulators took big leaps every new version bringing that dream closer every time. And look at where we are now, sure VR technology like display resolutions and FOVs should improve some more, but we are basically there already. Being able to already completely control a complex aircraft with just two hand controllers and some rudder pedals is mind blowing. Not even speaking about having traffic on the roads, incredible night lighting, great visuals, a very convincing flight model and so much more. There’s just not that much more to wish for in terms of large features (except for ATC, but thats already on your radar and maybe a better weather model some day).
I guess the days of flight sims making these big leaps are almost over now (although the competition still has a long way to go) and a lot of attention will go into the finer details. So if it is not possible to make what X-Vision did happen again, please take a look at what it does as I think it improves some of these details. It would be great if at least some of them can then be incorporated in a future version, I’m pretty sure it will help sell the sim through channels like YouTube. I understand if you won’t, it is your product after all, but one can always keep dreaming.
So great to be able to remove the unrealistic heating effect via the Shaders.txt file. The heating effect is only realistic when the plane is in parking or taxiing but once the engines deliver throttle, in reality there is no more heating visible near the engin, only a slight visible distortion.