GLTF Shaders are using too much space in ram

[Hexer611]

Hello, i have a project where i need to import glb files in runtime. I need all shader variants (at least that is what i think) so i included those in the build. I took a memory snapshot using Unity Memory Profiler, this snapshot belongs to a standalone build. I am not sure if this is a bug, is there anything i can do to decrease this ram usage?

[Phantomxm2021]

string[] tmp_ShaderNames =
            {
                "glTF-pbrMetallicRoughness",
                "glTF-pbrMetallicRoughness-Opaque",
                "glTF-pbrSpecularGlossiness", 
                "glTF-pbrSpecularGlossiness-Opaque", 
                "glTF-pbrSpecularGlossiness-Blend", 
                "glTF-unlit",
                "glTF-pbrMetallicRoughness-Blend", 
            };
            foreach (string tmp_ShaderName in tmp_ShaderNames)
            {
                var tmp_Shader = Shader.Find($"Shader Graphs/{tmp_ShaderName}");
                if (tmp_Shader)
                    Resources.UnloadAsset(tmp_Shader);
            }

Try this code this release the shaders.

[VrabelJannn]

We have the same problem on our project, and I'm afraid that releasing it is not the solution. Is there any statement from the developers? If native memory is allocated by 1.02GB, and two shaders need 0.8GB, it is more than suspicious :\

[azipf]

Still prevalent on our iOS built with Unity6 and glTFast 6.8. If you only have 2GB available, having nearly half of it just for those shaders is too much!

[atteneder]

Thanks for providing those insights.

Without doing further investigation I suspect the problem is the sheer mass of shader variants as a result of including all of them.

Unfortunately there's no generic quick fix, but I can think of solutions:

1. Tools that allow developers to reduce the number of included shader variants.
2. Alternative shader that uses dynamic branching instead of keywords and thus has fewer variants (see Dynamic branch shaders/shader graphs with less variants. #703).
3. Workflow that outsources shader variants in asset bundles/addressables and loads them on-demand.

Question regarding point 2: Would you be willing to accept a regression in render performance if this memory issue would be resolved by it?

[azipf]

In our case, we would be perfectly fine with the approach in point 2. Since we're using it as a more generic GLTF viewer and don’t always know in advance what assets we’ll be working with, it’s not feasible for us to manually reduce shader variants. A solution like dynamic branching would be a great fit for our needs.

[atteneder]

Thanks for the feedback, duly noted. I'll consider it in the planning process.

In case someone jumps ahead and crafts that solution, feel free to share and make a contribution.

[atteneder]

#703 might be a solution for this problem.