proceduralsky is painfully slow on android compatibility mode

[ahmad12331233]

Tested versions

4.3, 4.2, 4.1, 4.0

System information

android j2prime android j7 (or any 2016~ phone) godot 4.3 dev3

Issue description

+proceduralsky is really slow on android (20-30fps) on an empty scene
+when world environment sky is set to color or panorama the framerate is 60+

Steps to reproduce

+create empty godot project (gl_compatibility)
+add environment
+add proceduralsky
+export to android with remote debug enabled
+fps ~30
+now remove sky
+fps 60+

Minimal reproduction project (MRP)

N/A

[Az-qianchen]

Screenrecorder.mp4

I had a similar problem, but it seemed to return to normal when I accidentally removed the camera and reset it, but I could see that even the GPU didn't seem to run full, and after resetting the camera, the GPU seemed to run too low again.

Another problem is that in Android, when using Xobx handle control, shoulder button release does not seem to trigger, I do not know if there is a need to open a new problem report

[AThousandShips]

Please upload a minimum project to help with testing this, to see all the settings and details :)

• A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).
• Having an MRP is very important for contributors to be able to reproduce the bug in the same way that you are experiencing it. When testing a potential fix for the issue, contributors will use the MRP to validate that the fix is working as intended.
• Drag and drop a ZIP archive to upload it (max 10 MB). Do not select another field until the project is done uploading.
• Note for C# users: If your issue is not C#-specific, please upload a minimal reproduction project written in GDScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a .NET setup available.

[ahmad12331233]

Please upload a minimum project to help with testing this, to see all the settings and details :)

• A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).
• Having an MRP is very important for contributors to be able to reproduce the bug in the same way that you are experiencing it. When testing a potential fix for the issue, contributors will use the MRP to validate that the fix is working as intended.
• Drag and drop a ZIP archive to upload it (max 10 MB). Do not select another field until the project is done uploading.
• Note for C# users: If your issue is not C#-specific, please upload a minimal reproduction project written in GDScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a .NET setup available.

thanks for quick reply but even though i understand how important mrp is but this is device specific issue (j2_prime and j7_2016) its that the engine is slow even on EMPTY scene so mrp isnt needed but someone with the same phone is needed to test it

[AThousandShips]

That still requires an MRP, so please provide one to help with testing :)

[clayjohn]

Using ProceduralSkyMaterial and PhysicalSkyMaterial on low end mobile devices will always be a bit of a challenge as they dynamically calculate the sky color and they do it for every visible pixel of the sky. Mobile devices (especially low end ones) really struggle with both calculations in shaders, and running shaders for a high number of pixels. Having fully dynamic skies are just not a good idea for mobile devices.

Luckily, there are a number of things you can do to improve performance:

1. You should be doing this already but set the rendering/scaling_3d/scale project setting to a much smaller scale. For mobile devices, you can typically get away with a value of 0.5 without much noticeable loss in quality (depending on the style of your scene). Set it as low as you can while still looking acceptable
2. You can modify the sky shader to read from the reflection map when drawing the background instead of recalculating the background dynamically. This has the impact of "baking" the sky into a cubemap that you then use to sample. It results in similar performance to using the PanoramaSkyMaterial, and you only pay the cost of the shader when you update the sky (i.e. when you move the sun or change a shader parameter). To do this, convert the ProceduralSkyMaterial into a ShaderMaterial and then change the final line:

COLOR = mix(ground, sky, step(0.0, EYEDIR.y));

Into:

if (AT_CUBEMAP_PASS) {
	COLOR = mix(ground, sky, step(0.0, EYEDIR.y));
} else {
	COLOR = texture(RADIANCE, EYEDIR).rgb;
}

You will notice a slight delay when you move the sun, but otherwise it will look nearly the same and perform much faster on low-end mobile devices

[Calinou]

You can modify the sky shader to read from the reflection map when drawing the background instead of recalculating the background dynamically

This sounds like we could provide this as a built-in property in SkyMaterial or provide this as a project setting (with a mobile override that defaults to true).

[clayjohn]

You can modify the sky shader to read from the reflection map when drawing the background instead of recalculating the background dynamically

This sounds like we could provide this as a built-in property in SkyMaterial or provide this as a project setting (with a mobile override that defaults to true).

I've thought about doing this, but I'm not sure how many people would find it useful.