Graphics card profiles: Difference between revisions
m (trying a different form of quoting via instant-cquotes ...) |
(→Idea) |
||
Line 4: | Line 4: | ||
This idea dates back to early 2016 when a few FlightGear contributors were discussing a reddit review of FlightGear which highlighted that FlightGear's default graphics settings didn't seem to fit/match the graphics hardware available. | This idea dates back to early 2016 when a few FlightGear contributors were discussing a reddit review of FlightGear on the forum which highlighted that FlightGear's default graphics settings didn't seem to fit/match the graphics hardware available. | ||
FlightGear core deveoper Erik Hofman came up with the idea to preselect more appropriate default settings based on parsing various GL_* strings (in particular GL_VENDOR), i.e. detect the video card and based on the GL renderer name turn on [[ALS]] (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc. | FlightGear core deveoper Erik Hofman came up with the idea to preselect more appropriate default settings based on parsing various GL_* strings (in particular GL_VENDOR), i.e. detect the video card and based on the GL renderer name turn on [[ALS]] (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc. |
Revision as of 16:59, 24 February 2016
This article is a stub. You can help the wiki by expanding it. |
Idea
This idea dates back to early 2016 when a few FlightGear contributors were discussing a reddit review of FlightGear on the forum which highlighted that FlightGear's default graphics settings didn't seem to fit/match the graphics hardware available.
FlightGear core deveoper Erik Hofman came up with the idea to preselect more appropriate default settings based on parsing various GL_* strings (in particular GL_VENDOR), i.e. detect the video card and based on the GL renderer name turn on ALS (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc.
The defaults would not be touched but based on the detected video card certain options would get enabled, making the first impression much more pleasant (for first time users). [1]
Furthermore, suggesting that it could be a good idea to make sure the configuration has at least 20fps at KSFO. Also it would be a one time configuration for after a (re)install. The settings would be written to a local configuration afterwards so users could still tweak for their own liking.[2]
Other contributors, like Thorsten mentioned, that it does not seem to be a technical problem - to query a string from the property tree is easy, to write a routine which sets other properties based on what the string says is equally easy. The problem is the meat of it - someone has to know what settings are likely to run on what graphics cards. And someone has to write the routine that does it. Then it's done. [3]
We can do that by settings /sim/rendering/* as required, i.e. loading pre-configured profiles from $FG_ROOT CPU/RAM and VRAM info is not currently available, but we have patches providing this sort of info [4] :
Resource Tracking for FlightGear
For example, $FG_ROOT/gui/dialogs/about.xml and rendering.xml are already accessing some of the GL* data via properties, e.g. to display the Intel warning, but also the GPU vendor info: About dialog
Thus, we would ideally introduce 3-4 "vendor"-specific folders and then introduce a PropertyList XML file where the RENDERER string is used to select a certain default configuration. For testing purposes, we could promote this features on the forum/website/IRC and facebook to get people involved with testing, and to provide feedback - so that we know what settings work well enough, using Nasal's http APIs, such feedback could even be gathered online. [5]
- ↑ erik (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
- ↑ erik (Feb 8th, 2016). Re: Review of FG on reddit: xpost.
- ↑ Thorsten (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
- ↑ Hooray (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
- ↑ Hooray (Feb 8th, 2016). Re: Review of FG on reddit: xpost.
Approach
Note In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).
While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible. |
that's basically a form of feature-scaling: Feature Scaling
Like you say, we could expose most of the GL* info at the property tree level, and then use Nasal/propertylist rules to dynamically toggle features on/off during startup, i.e. sort of a better customiable initialization sequence. The easiest way to implement something like this would be supporting "data overlays", i.e. in the form of fgfsrc/preferences.xml files that are stored in $FG_ROOT/Profiles and automatically overlaid over default startup options once a certain GL vendor/make and GPU model are detected, e.g. by having:
Each vendor-specific sub-folder could then contain graphics related xml overlays that will be loaded on top of the default startup options (i.e. those not customized/overriden by the user) - what that means is that the current hard-coded default settings in fg_init.cxx would need to be dynamically loaded during startup using the APIs from props_io.cxx. The corresponding startup profiles could be either conventional PropertyList XML files, or support embedded Nasal/property-rule blocks to provide support for regex-matching etc. |