Add a 3D graphics settings demo

[Calinou]

Similar to the Input Mapping GUI demo, I think we should have a demo to configure 3D graphics settings. This is a common question on community platforms and there's barely anything about it in the documentation.

Values should be persisted and should be applied without requiring a restart as much as possible.

The TPS demo has a graphics configuration menu, but the project itself is not particularly minimal and doesn't lend itself well to reuse/copy-pasting.

[smix8]

@Calinou
The TPS demo also has only a minimal amount of 3D options included.

A demo that would reflect real 3D games with runtime changes would have over 50+ settings if you want to cover everything cause it is not only about changing Viewport, Light, Shadow and Project settings but also how to apply this to a 3D environment to e.g. change texture and model resolutions if you turn on low or high graphic settings.

I mean I have everything ready and working in a Project but ripping it out to a small demo would take some time so I would be glad if we could make an example list, e.g. look at a typical Ubisoft game as they have basically settings for everything and determine what is needed and what not for a demo.

[Calinou]

A demo that would reflect real 3D games with runtime changes would have over 50+ settings if you want to cover everything cause it is not only about changing Viewport, Light, Shadow and Project settings but also how to apply this to a 3D environment to e.g. change texture and model resolutions if you turn on low or high graphic settings.

For indie game use cases, having 50+ settings isn't really practical. Not only it's difficult to use such a menu effectively for most players, but exposing multiple texture resolutions is also less relevant since texture sizes are rarely that high in the first place. It's possible to halve texture resolution at load-time, but this requires a restart and it will also affect 2D textures, making menus/HUD blurry.

As for model level of detail, this is generally handled by having a LOD bias setting. This is already available in the master branch, but can't be backported to 3.x because there's no built-in LOD system.

I think what the TPS demo exposes is a good start, but there needs to be a few more settings available, especially for level-specific things such as hiding non-essential lights or disabling their shadows. This can be handled with groups relatively easily, but it should be demonstrated.

[smix8]

I don't understand where and by whom this quote was posted.

... but back to topic. I have a timewindow next week to create such a demo with some 3D assets from the TPS demo that take less than 10 mb total so should end up small enough for a demo (my own assets don't fit Godot's demo standard). Should I then prepare a draft PR for discussing the implementation details?

[Calinou]

I don't understand where and by whom this quote was posted.

It was posted by GeorgeS2019 who removed their comment after I replied.
Edit: I also removed my reply since it's no longer relevant.

... but back to topic. I have a timewindow next week to create such a demo with some 3D assets from the TPS demo that take less than 10 mb total so should end up small enough for a demo (my own assets don't fit Godot's demo standard). Should I then prepare a draft PR for discussing the implementation details?

Sure 🙂

I would keep the "game" code as simple as possible and focus on the graphics settings menu itself.

[Calinou]

@smix8 Did you have time to look into this? If not, it's fine; just let me know so others can work on this demo project if they desire so.

[smix8]

@Calinou
tbh I started working on it but when other things came up in May and smashed my plans for the year I completely forgot about this. I might as well finish what I started but can't provide a reasonable ETA so if someone else wants to work on this I don't mind.

[smix8]

Well ... that escalated.
@Calinou
... please send help, I am stuck on the dancefloor and don't know how to stop.

[Calinou]

Well ... that escalated. @Calinou ... please send help, I am stuck on the dancefloor and don't know how to stop.

Looks good 🙂

Some comments:

• 12× anisotropic filtering is not supported on most hardware; only powers of 2 are valid values (up to 16×).
• 16× MSAA has a tendency to break things (on top of being extremely demanding), so I wouldn't expose it.

[smix8]

After adding and testing all kinds of lens flares, god rays, glow and bloom settings ramped up to 11 for hours with more than a few critical "flashing light" failures I have hard non-medical proof that I am not an epileptic.

@Calinou
16x MSAA is not part of any of the presets but since the option exists on all viewports it is included for completeness.
I think possible settings should be exposed so hiding unwanted functions is just a matter of hiding the control in the menu.

Here is a link to a long image with the current settings. Some are placeholders for Godot 4.x features or popular addons. I would prefer sharing the project for testing but I guess I need a week for project cleanup first ... lol.

Settings

https://user-images.githubusercontent.com/52464204/149713947-a6a1b96a-35b5-4dfd-9c90-cda3af30cc8f.jpg

[Calinou]

@smix8 Remember that demo projects should be relatively small, so that they can be uploaded to GitHub Pages (for HTML5 testing) with ease. The PCK file should weigh less than 20 MB once the project is exported, since GitHub does not allow pushing files larger than 20 MB since 2020.

We can automatically downscale textures for the HTML5 export if needed, but I'd still prefer the demo projects repository to remain relatively fast to clone for people with slow connections.

[smix8]

I never exported for HTML5 I have no idea, can it even run more sophisticated GLES3 stuff?

There are not many textures or external 3d models in the project. Nearly everything is made with Godot build-in Resources. The biggest filesize offenders are the baked lightmaps and the vertex animation textures for the crowd and the vertex texture can't be compressed for obvious reasons, only cut short or removed entirely if 20 mb is the target.

In an ideal world we would have two demos, one for mobile / html5 / integrated graphics and one for desktop hardware with dedicated gpu and only GLES3. I fear most mobile hardware will catch fire anyway if they hit the "ULTRA" button by accident.

[smix8]

@Calinou
After some excessive optimization on all assets the project export .pck file is down to ~10 mb ... at least for the windows export.

This does not change the current fact that the HTML5 export is a broken, visual mess and I don't know what is causing the corruption. I think it is a shader issue cause everything with a default SpatialMaterial shows up unshaded while everything with a custom shader is black.

I mean both editor HTML5 play and exported HTML5 load everything without causing errors but then the demo runs at atrocious framerate even on lowest settings and half the assets are black or missing entirely.

EDIT**
I used the Firefox Developer tools and it is spaming

"ERROR: Condition "!version" is true. Returned: -1 tmp_js_export.js:362:18 at: _get_uniform (drivers\gles3/shader_gles3.h:432) - Condition "!version" is true. Returned: -1"

Any Idea what I can do with this error and how to fix it? Firefox and all drivers are updated and I tried with and without hardware acceleration turned on.

[Calinou]

I would recommend not including any custom shaders in the demo. In fact, even including a custom theme in the first place should be avoided. The demo should be as simple as possible to integrate into an existing project, even if that makes it look less pretty. (Godot 4.0 will have a new default project theme that looks better out of the box anyway.)

The demo does not need to be exhaustive; it just needs to provide a good starting point for graphics settings menus.

Any Idea what I can do with this error and how to fix it? Firefox and all drivers are updated and I tried with and without hardware acceleration turned on.

It sounds like one of the shaders is failing to compile.

[smix8]

@Calinou
Here is what happend with the broken HTML5 export.

A single SpatialMaterial on a small Sphere Mesh that had Subsurf Scatter enabled turned nearly the entire scene black.

Are there known bugs with HTML5 exports and subsurf scattering that I should be aware of? I was literly only changing albedo color and enabling subsurf scattering on the SpatialMaterial but that was enough to break the entire scene on the HTML5 export.

[Calinou]

A single SpatialMaterial on a small Sphere Mesh that had Subsurf Scatter enabled turned nearly the entire scene black.

Screen-reading shaders tend to not work reliably when using GLES3 on HTML5.

As a workaround, I would recommend conditionally disabling subsurface scattering in HTML5 using if OS.has_feature("HTML5").

[voylin]

Is there any progress on this? Else I would like to give this a try as I have made a graphics menu with ui scaling in a game I made (would be for Godot 4.0).

[voylin]

I gave this a try, see PR #713.
Was this the kind of settings menu which you wanted as a new demo @Calinou ?
There is a screenshot which shows all the possible settings.

[voylin]

I guess this issue can be closed as we have a 3D Graphics settings demo now, right?

[Calinou]

I guess this issue can be closed as we have a 3D Graphics settings demo now, right?

Yes 🙂 Thanks a lot for contributing the demo!

[voylin]

I guess this issue can be closed as we have a 3D Graphics settings demo now, right?

Yes slightly_smiling_face Thanks a lot for contributing the demo!

I should thank you and all the others who have been helping me on this whole contributing journey. I've learned so many things and I even have an open pull request on the engine itself. Thank you for helping me to get this far. 😄