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.
Very interesting bit of a philosophical post, Ben. Good reading. I have no issues with the approach, and will watch (and use) with enthusiasm. My only suggestion, with regards to the various expert level weather and render engine manipulations, is that the pertinent datarefs be elevated to the public level so that they can be accessed via plugin. While one can tweak these elements with Dataref Editor, those tweaks are not permanent. A plugin approach would be able to add custom code to manipulate on the fly and store the configuration for next time – something I don’t think is possible with the DRE tweaking approach. In some respects, using DRE is kind of like using a custom screw. 😉
Thanks for what you guys are doing. Clearly you’re fighting a war on many fronts.
They are already accessible! Art controls live in sim/private/controls/XXX I think. And I have a plugin laying around that pokes them at startup from an ini file…I can post the source one of these days if someone wants to turn it into a something.
One reason why the art controls are in sim/private is that they are _not_ considered stable. LR makes _no_ effort to ensure that the low level engine tweaks are going to be the same from one patch to a next…rather we’ll change them as needed since they directly reflect the underlying implementation of the engine!!
Very int. post. I think it’s a great idea to keep it simple. One thing that demolish the FS platform is the overkill of settings and option for tweaking. The new XP10 is just rocking and the waether engine is a pure joy an provides a lot of int. challenges. The sim is by far realistic, I still catch myself clinching to the armchair in how realistic this sim is, especially with a combination with openstreetmap. If anything, you should keep the focus on holding the performance level at the current place, as we all know how things impact fps as new things are implemented.
Keep up the good job providing us with an framework for flying and with that an simulator that runs efficiently and fast.
Sounds like a sensible approach. I don’t like the Apple world because it’s restricted and I don’t have freedom there.
Ben so is there a configuration file as in FS9 and FSX and if so where is it? Not that I would ever screw around with it . I know with MSFS you could just delete the Config file and it would build a new one on startup of the sim setting everything back to default if you did mess up .
Resources/settings.txt
And…I just realized: since that file edits art controls, you can hack it to pre-program art-control configs in the sim. Who knew?
As you collate others in their render settings you usually find you are all not that much different, the power and the speed of different machines do allow some to run more or less than others but really across the board we all end up at basically in the same place,
There is one point in the fine tune…I find there is jumps in settings that are to big or wide, i would like to be somewhere in between, It is to say it is now 1 -6 instead of a wider setting of 1 – 10,
in textures certainly the gap is too large and this is certainly for machines of lower power & speed, In this area it would give you more flexibility to tune it far closer to your machine.
Nice idea. I’m sure this can be difficult in practice as you need to be able to anticipate what impact a particular combination of settings will have on the system.
Here’s another idea. Allow the software to perform a series of performance tests with various combinations of rendering settings, to determine the cost/impact of each particular setting. This could be an automated process that repeatedly reconfigures rendering settings and then runs the simulation through a specific path (pre-recorded flight trajectory in one or more locations). This might take several minutes or longer, but if it’s automated the user can come back later after the tests have been run. Based on the results of the tests, the system automatically selects settings that perform well, and also visually indicates which settings are cheap and which settings are expensive, allowing the user to choose what’s important to him/her, while understanding the costs. Would be awesome to be able to click “Auto-configure” and then just start flying!
Ben, I am sorry if my question is a bit off topic here but I hope it is not too far off and you will respond.
I have heard many complaints and I have to join the crowd here..
despite many wonderful things version 10 has to offer and constant improvements, there is one thing that still is very disappointing.
The big cities, little auto generated houses on approach or low VFR flying look great but when I am approaching NYC or Philadelphia, I do not see any high buildings or if , there are just a couple and the city does not look like a one at all.
Is there something planned down the road to fix/improve that?
I would say it is the most important item on my wish/fix/improve list. 🙂
Thank you for you great efforts in improving X-Plane.
Cheers, Andrzej
Yes – we are working on this!
I agree, the out-of-the-box setup should be better-tuned than the average user can achieve. This is why I suggested a couple of months ago that you have a benchmarking program to test the actual performance of target platform specifically for the loads X-Plane imposes. This would create the rendering preferences profile that will give at least, say, 25fps with real weather.
Hi Ben,
Interesting article, however I think that analogy with the car engine is not quite representative for clouds settings. Car engine analogy does not take into account eye candy and realistic appearance of the clouds contra performance of the simulation. Tuning car engine has only effect on car performance but not on how car appears externally. Therefore I thing that analogy is more applicable on aircraft flight dynamics model. (How many requests do you get to put those settings in the simulator?)
Settings control that I’ve been asking for is more of external car design nature.
Give us option to choose car with a lot of details and thus more drag and less performance or less external details thus less drag and better performance.
You should not choose for users which car suits best for them. That’s why car manufacturers has whole bunch of different models. They give users options to choose.
Regards,
NenadJ
That’s why there still is a cloud slider to trade off detail vs. performance!
Is the lowest cloud setting in Beta 6 higher than the lowest cloud setting in Beta 4? I only ask because I saw some performance degradation when moving from b4 to b6 on my two networked computers, both of which already have pretty low settings.
Congrats – on my MBP mid 2009, with a fair amount of detail and screen res not set to full screen, I’m getting 25-30 fps – good going!
Very interesting article as usual.
My question might be off topic as well but, it would be very nice if Laminar had some kind of a message board to submit bug reports, a bit like JRollon does. First, we would be able to know if someone else experienced an issue. Second, this might limit the various submissions of the same bug by different people and third, people could comment or participate to a bug that was already submitted, adding technical details or screenshots to allow you to better understand the problems.
Also, another suggestion following this route:
I think there should be “bug report” section on the forum, but also an MR section “modification request”. I personally have submitted “bugs” that were not bugs but problems with the design in my opinion (refer to “runway visibility and edge lights intensity” bugs I’ve submitted).
I think they would belong to an MR section on that message board.
And I understand you already have a lot of work and that creating a message board would be more work for you.. Is there a reason why you prefer to go with an offline form ?
thank you
Patrick B.
Ben and Crew,
Quick question, is there a way to increase the size of the skycolor PNG’s? A config file or something. Been looking around and I do not see anything. Reason for this is I wanted to try billboarding onto the skycolors clouds using photoshop and the current sky textures are way too small….. 🙂
No – they can’t be customized. And they’re not just used “as textures” – I think it’s not that simple, so I don’t think this will work. you need imposter geometry.
Thanks for the reply,
I really want to run with this. Could a work around be as simple as rendering a high resolution image after the skycolor is rendered but before the terrain?
Maybe something a plugin could handle?
Keep in mind I am no programmer but I think with the proper guidance I could pull it off…. 😉
best,
John
Yes, a plugin can render clouds, particle systems, cloud imposters, whatever you want.
I hate to be such a noob but can you point me in the right direction…I need a foundation to work with…..
Pretty please with sugar on top….:-P
I rename my sceneries in order to keep a good oversight. I’ve done that with the initial install of the Aerosoft package, too. I kept some of their sceneries, I deleted some others because there is better freeware available.
Now I wonder if everytime I run the updater X-Plane will reload the Aerosoft packages? Or is this a one-time event with this update only?
(oh… and how is 64-bit coming along?) 😉
Markus
If you rename scenery packs, the updater will re-fetch them!