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.
]]>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?
]]>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
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). 🙂
]]>Yes… I got it all better now .
Thank you Ben,
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.
]]>“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.
]]>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.
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!
]]>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.
]]>