X-Plane 10.36 has a button in the rendering settings screen labeled “set all rendering options for maximum speed”. Our recommendation for tuning your X-Plane settings has been to start low and build your way up, so that you don’t end up with one setting “hanging” the system at a low framerate (which stops you from seeing the affect of other changes).
This button was a good idea in principle, but in practice it had a few problems:
- The lowest settings are really just astonishingly ugly.
- Some of the settings that get turned off are nearly free, so pressing the button hurts graphics quality unnecessarily.
- Once you minimize your setting, what do you turn up? I’ve seen too many forum posts where users have picked a few random expensive settings and complained about a poor trade-off (e.g. poor performance for the hardware and quality).
So in X-Plane 10.40 we’ve replaced this single button with five pre-made presets: minimum, low, medium, high, and extreme. Each preset is hand-built to try to make good settings trade-offs; instead of having to fish for better visual quality after minimizing, you can simply try 2 or 3 presets, based on your hardware. If you have a very new system, try “high” and “extreme”. If your system is really old, try “low” and then go on to “minimum” or “medium.”
The settings aren’t coded into X-Plane; they come from a config file, and this is important for the process of tuning the presets. The truth is: the presets as picked in beta one are probably not that great. I did run them on my machines, but with only a few computers, it’s hard to know what a good setting is for most users.
In X-Plane 10.40, it will be possible to run the framerate using one of the rendering setting presets instead of one of the fps-test numbers. This will let us get direct, controlled measurement of the performance of specific presets on real machines. My hope is that by collecting this data and tuning the presets up and down, we’ll be able to dial in good compromises in terms of speed and quality.
I’ll post details on how to use the fps test once 10.40 goes live, so that we can start collecting data.
In the long term, the rendering settings need a lot more than just presets; they need a massive simplification. But within the scope of X-Plane 10.40, the presets will hopefully provide a better user experience, less time spent tuning X-Plane, and be a good stepping stone toward a better UI.
Finally, for advanced users who like to tweak things: it will be possible to edit settings.txt and change the presets. I see this in the forums a lot:
User 1: I have an Intel i7 clocked at 1675 ghz and I’m getting 10 fps. What’s wrong with X-Plane?
User 2: that’s weird – I have an Intel i5 clocked at only 900 ghz and I’m getting 350 fps!
With the presets, user 2 can build his settings into a preset and send the file to user 1, who can then try those exact settings and see how performance runs. Both users could also run our presets in the fps test and see if the performance problem is due to different hardware, different rendering settings, or different add-ons.
Woow!!! last time we hear only good news, i think is a good feature, and personaly, i dying to test these famouse 10.40, soooo… i do not ask it 🙂 because i know…ok , i go ahead. when expect out the first version of 10.40?
Will include seasonal textures as you promise?
10.40 will be a really huge chage of X-Plane, and as you told i think will be in beta for a longer time, but maybe will be a good idea to start devering changes.
Good work XP team, and congratulation for the hard and great work your doing!
Hi Alex,
I am 100% sure I have not used the word “promise”, because I never use the word. No feature is certain to ship until it is done, so I don’t promise things that are not certain.
With that in mind: 10.40 allows third parties to change art assets in the library based on any dataref, built-in or from a plugin. This allows a developer to create terrain textures and art assets that reply to the time of the year (as well as other variables). This code is in 10.40 beta 1.
10.40 does __NOT__ contain new versions of our entire default terrain textures for every season. I hope that is absolutely clear.
The feature here is putting a hook in the _engine_ so that third parties can make seasonal add-ons without having to write scripts that edit the X-Plane folder directly.
good news !!!
could this also allow to change art assest e.g how the wet runways looks like ??
cheers !
Only art assets in the library – runways aren’t in there now. But you can do terrain, buildings, etc.
If we are speaking about ground textures..
Is there any new textures coming with 10.40?
I really like textures in the US , and in some parts of europe , however in central europe IMO open fields should be much more green.
As for what you did for third parties developers , it’s really great!
I hope that will come a developer soon that will use this in order to enhance ground textures.
No new textures in 1040.
I forgot “, “promise”, hihi, you are totaly right, was a bad joke :).
I understand it.
But in future you planed to extend theses conditions to custom elements too or will be used only for library based ? Certainly, i noticed you, there are elements of roads that are not mapped to library.
I think will be great to apply same algoritm if is posible to custom objects/poligons, that will gain more than anothers simulators.
Anyway, thank you a lot for reply!
There are elements of the road not mapped to the library, but the -entire- road system is mapped to the library, so it can be replaced as a whole.
We are not going to map individual -image files- ever, because it’s not safe; if the organization of the image were to change, all library-based replacements would result in nonsense-based texturing. That’s why you get the .pol in the library, not the PNG it uses.
Yes… I got it all better now .
Thank you Ben,
Hey Ben,
this preset-freature is just awesome because I see it could be used in a slightly different way. Right now I’ve got the perfect rendering options for me and my system, but when I accidentally click on “Reset Settings” after X-Plane crashed, I have to set all again. And now it would be possible for me to just edit the preferences so that one of the preferences is my own. Great stuff!
And it would be possible to have two rendering settings saved all the time. Often I change the settings when flying in populated areas (who needs clouds or trees? – I need buildings, cars & roads!) but when flying through Alaska my PC has got some graphics power otherwise unused (I love clouds and trees! Alaksa has so few buildings).
So yeah, that’s a pretty nice feature! Looking forward to 10.40…
Kind regards,
Leo
This one clic rendering setting based on a customizable settings.txt file is just great!!!
i do use 2 different rendering settings when flying slow pistons vs fast complex heavies payware. As of today i had to go to rendering and tweak manually couple of settings to my liking manually back & forth, now i am one clic away 😀
how hard would be to support a per aircraft joystick settings and axis assignments as well? i do still have to re-assign axis and tweak rudder/aileron sensitivities when flying different aircraft for an improved feeling.
thanks Ben, very exciting times
Per-aircraft and per-device presets for joystick is something that we planned for when we rewrote the joystick support.
awesome, thanks!
Ben,
Just to clarify, will we still be able to tweak the various items in the rendering options as we do now or will we be “locked” into one of your presets?
Thanks,
John
You can definitely change things – the presets “configure” the screen, but nothing is locked. So you can pick “medium” and THEN turn the texture res up to extreme if you have an older GPU but the GPU has a ton of VRAM, for example. Or you can pick “extreme” and then turn down the anti-aliasing if you want to run full screen at 4k.
Hi Ben,
In the future might it be possible to have some rendering settings dynamically tuned while in flight based on system load? For example I love the cars feature and it works great with little FPS impact at any setting when I fly in rural areas, but if I fly over a city it can have up to a 10FPS performance impact. It would be awesome if there were settings for some graphics options along the lines of “if resources available”. For example if I had cars on and were to fly over a city the cars setting would automatically be turned down to minimum or even off. I realize that this would not work for rendering option changes that require reloading the scenery, but for things like clouds and cars it might be able to offer a much more consistent FPS experience over varied terrain. This suggestion comes from a personal annoyance flying X-Plane where I will sometimes need to stop and change my rendering options mid flight because they work great in some terrain/conditions but not others.
Honestly, probably not. We used to have this (back in version 6) – Austin would lower visibility to maintain fps.
The problem is: that worked well when the engine was very simple and therefore lowering visibility pretty much always lowers framerate. But at this point it’s impossible to know -which- setting must be lowered to fix a low fps condition.
What we can do in the long term (this requires a LOT of code to change) is build rendering algorithms whose limits are based on resource usage and not algorithmic limits. Here’s what I mean:
– Right now the car popup is based on a number of spawns per road segment. This creates realistic distributions but also means the CPU cost is proportional to the roads nearby – high in LA, low in Kansas.
– Better would be to have a fixed car budget, distributed evenly if possible – that way you wouldn’t get killed at high settings. (On the other hand, if you have a high car budget, applying it in the middle of nowhere might look funny.)
– Best would be a fixed -time- budget, where the sim gets a certain number of ms to process cars, and isn’t allowed to spawn new ones while that processing is taking too long.
Most rendering settings are in this first bucket: simple settings based on the scenery itself. This is what makes tuning the settings so hard!
Would it be possible to quickly see if the low framerate is due to CPU or GPU? And then which settings affects mainly GPU or mainly CPU?
There isn’t an easy way to know if the setting hits the CPU Or GPU. Some are obvious but some depend on the driver.
English is my second language so many times I am not understood the way I meant to be.
If I had to come out with 3 reasons explaining why I like XP over other platforms, it would be:
– realistic flight model
– ability to create any custom flying machine imagined
– constant work of LR Team to make the simulator even better with every release.
I am really impressed with what relatively small team can do for simulator, great work guys. 🙂
Sine this thread (in my understanding) is about XP future development I would like to ask where on the XP “To Do” list and what is the level of importance of 2 items described below:
1. Making new one or fixing existing XPlane2Blender exporter
2. Making the bigger cities look better ( more buildings than now). As we know, right now, flying over NYC is like we already went through 3rd World War…
Keep up a great work guys!
Well, it wasn’t SUPPOSED to be a “future of x-plane thread”, but we’ve gone this far off track, what the hell.
1. This is happening now – we’re working with Ondrej to get the 2.7 XPlaneToBlender scripts to support everything needed for scenery, aircraft, and migration from 2.49. I think the end result is going to be really good.
2. This is being worked on. I don’t know when it ships.
Please allay my fears:
“In the long term, the rendering settings need a lot more than just presets; they need a massive simplification. ”
If you move complex rendering settings to a config file, then “tweakers” will have to exit X-Plane to tweak.
The rendering settings as they are could be described as a bit “folksy.” Having even more complex settings would be great, especially if they were more accurately described. “Melt your GPU” is a fun way to write “Extreme” or “Most Demanding,” but this is where a more mature bit of polish could be applied to the sim.
In my friendly opinion, your smartest move, Ben, is to keep going the way you’re going, but have a simple rendering settings checkbox and a complex rendering settings checkbox. Simplification would benefit many, but not all, and many could actually be significantly disadvantaged. Give tweakers all the tools that they can stand, but give the noobs the ability to throttle with something more simple. Best of both worlds, and something many potentially challenging applications already do.
Hi Steve,
In the long term, tweakers who want more flexibility (and a good chance to shoot themselves in the foot) will need to move out of the rendering settings and into settings.txt.
This is actually a faster way to edit though, if you’re up for a challenge:
– Settings.txt works by adjusting one or more art control private datarefs for each setting dataref.
– To model settings, you edit those datarefs -directly- in DRE…X-Plane doesn’t thrash them until you go to the rendering settings screen.
– You may have to periodically change airports to force a scenery reload, but you can adjust a lot of settings, and some are real-time.
And for the realtime settings, DRE is a HUD – that is, you can see the setting change as you type.
It’s tweaker’s paradise!
But…for _normal_ users, whose idea of X-Plane is to fly and not to adjust popup menus and wait for the sim to reload, the current settings are a bit of a disaster. There are too many, there are too many combinations that result in silly looking rendering, and it’s not even remotely obvious how to fix a performance problem.
Good one, but not implemented the best way.
Why.
1) Your “official” presets should stay untouched. Because then we are all consistent on what it means “if have it on high”.
2) You should allow us to save custom settings. Either with automatic naming (so if a user edited settings after he selected extreme, the custom setting will take its place as extreme-custom-1), or let the user freely name it. THOSE should be the settings saved in the ini file (which I hope will be XML formed).
In any case, definitely a move to the right direction (read: to the 21st century). 🙂
some thing still very wrong with your render
2D trees should not kill the frame like it is nor should buildings on top end cards
i have noticed there is little change in frame rate from 1080p up to 4k in the same scene
CPU, GPU, ram no where near maxed out but frame rates in the low 40’s to mid 30’s
with EVERY SETTING MAXED OUT