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.

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.

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

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

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?

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

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.

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

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.