I'm listening to Marco Arment and Dan Benjamin debate whether a user setting could have avoided the incident where a man's iPhone rang during a concert. I also just finished reading the Steve Jobs biography. It got me thinking about the trade-offs between a closed non-configurable system and an open, configurable one. This comes up in an X-plane context every time we poke at the cloud rendering settings and someone asks whether we can put in more settings for additional configuration. What trade-off is right for X-Plane?
Chris suggested an analogy to me a few weeks ago that I think is pretty good: tuning the rendering engine in X-Plane should be like tuning the timing in your car. It should be possible, if you are a serious expert and enthusiast, to change the tuning (and if doing so wrecks your engine, well, you were asking for it by opening up the engine), but it shouldn't be easy. Regular users of the car expect the manufacturer to have a lot more expertise, and to set the timing to an optimal setting up front.
I think the same thing goes for X-Plane. I should use as much expertise as I have to maximize efficiency no matter what trade-off is being made; at no point should dialing in a setting result in stupid behavior inside the engine. It's up to me to know what can be inefficient and avoid that happening.
So: the rendering settings are going to remain as simple as possible, and any time we can make them more simple, less likely to be set up wrong, or any time we can realign them to be better aligned with user constructs ("more houses") instead of internal constructs ("higher instancing density ratio!") we'll take that win. It should not be the user's job to tune the engine, and any time that is necessary, that's a failure by me to pre-tune the sim, not a feature.
I don't think we are even close to the kind of rendering settings that are really useful to non-expert users; one of the frustrations with performance tuning over the last few months has been the number of times a user has sent me rendering settings and it was clear that the settings were inefficient for the given hardware.
The answer is not to try to make every user into an expert in the OpenGL pipeline; the answer is to change the settings so that users don't have to be experts. This is not easy to do; the reason it's not done yet is that we will have to create new code and do real hard work to make the interface simple. One theme that both Steve Jobs and Jonathan Ive describe when discussing their design philosophy is that, to make something simple in its final product, you have to dig down and master the complexity that you want to get rid of. To make the rendering settings simple but still powerful, we are going to have to solve these performance-efficiency-hardware problems ourselves and encapsulate that knowledge in code, and that's not trivial.
Underneath the settings are a whole pile of art controls, and if you really want to, you're more than welcome to enter any value you want in there. If you discover that you're better at tuning the engine than I am, I will be very happy to hear what you did!
This attitude is not as extreme as the "Steve Jobs" approach; Apple devices often use custom screws to ensure that normal people can't open their devices even if they want to. We are hiding implementation out of sight, but we are not locking that implementation at all. The settings file is plain text, the art controls are viewable with a publicy available plugin (DataRef Editor).
X-Plane has always been a hackable sim, and one of the things I used to enjoy back in X-Plane 6 was just looking at all the stuff in the resources folder; the raw textures were pretty amazing to view in themselves.
My goal here is not to take that away; only to make hacking and opening up the sim something you can opt into if you are curious, instead of something mandatory to get good performance.