Make it easier to change graphics settings at runtime

[xxSeys1]

Describe the project you are working on

I and multiple people I know are working on 3D games and all find it difficult to make a graphics settings menu

Describe the problem or limitation you are having in your project

It's really hard to make a graphics menu, because the settings seem to be scattered all around different engine singletons seemingly at random. Also a lot of settings exist multiple times and it is not clear when to use which. It makes creating a graphics menu a very slow and tedious process that is quite demotivating.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Option 1
Have a single engine singleton called GraphicsSettings which contains a reference to all of the necessary settings for a graphics menu (basically everything graphics related in the project settings). The syntax would be for example GraphicsSettings.set_positional_shadow_atlas_size(Vector2(1920, 1080)).

Option 2
Improve the documentation on where to find what graphics setting and when to use what. Maybe have a small tutorial about that.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See Describe the feature / enhancement and how it helps to overcome the problem or limitation

If this enhancement will not be used often, can it be worked around with a few lines of script?

Graphics settings are something a lot of games need, so this is nothing that can be easily worked around.

Is there a reason why this should be core and not an add-on in the asset library?

It affects the graphics settings.

[Calinou]

• Related to Add project settings to globally disable resource-intensive Environment features #5229.

Option 1 sounds too specific to me, as it would then create a disconnect between the actual singleton doing the job and the setter/getter. This would also be inconsistent with input, audio, networking, etc.

Regarding option 2, we have a graphics settings demo project: https://github.com/godotengine/godot-demo-projects/tree/master/3d/graphics_settings

Like the input mapping GUI demo, it's intended to be copypastable in your own projects as easily as possible. (If this is not the case, please open a pull request 🙂)

The demo could be accompanied by a general documentation page about settings menus, which would point out the various demos implementing those as well as best practices.

Most project settings' descriptions already tell you which method you should call to set a property at runtime, but I know some are missing. I've been working on RenderingServer and RenderingDevice class reference and have added more of those hints in the process.

[xxSeys1]

The demo was suggested to me a few hours ago in the godot discord and I instantly copy pasted it into my project :)
I think documentation about settings menus would be great, since such documentation existing could have saved me the two days it took me to find the demo.

I don't know if you have added this already, but it would have been really helpful if the RenderingServer docs would include that this is the singleton where most graphics settings are located and where they should be changed, as this would eliminate confusion because some settings are changeable in the viewport class as well if I'm not mistaken.

[Calinou]

I don't know if you have added this already, but it would have been really helpful if the RenderingServer docs would include that this is the singleton where most graphics settings are located and where they should be changed, as this would eliminate confusion because some settings are changeable in the viewport class as well if I'm not mistaken.

Many per-viewport settings can also be changed in RenderingServer (functions which require you to pass a Viewport RID), but this is a lower-level API. I recommend using get_tree().root to get the root Viewport node and set properties on it when possible to benefit from the high-level API (such as property syntax).

[clayjohn]

See also #2183

Personally, I think this would be best solved by adding more overrides into ProjectSettings like what is suggested in #6612. A new singleton would be too messy.

As a note, our goal with 4.0 was to move all performance related settings into ProjectSettings. The only things that aren't there are things that are equally related to style and performance (like per-viewport shadow resolution settings, or the number of steps to use for screen-space reflections).