Los Shaders son programas pequeños que se ejecutan en el GPU y cargarlos puede tomar algo de tiempo. Cada programa del GPU individual típicamente no toma mucho tiempo para cargar, pero los shaders a menudo tienen muchas “variants” internamente.
Por ejemplo, el Standard shader, si se compila completamente, termina siendo miles de problemas de varios programas de GPU diferentes Esto crea potencialmente dos problemas:
While building the game, Unity can detect that some of the internal shader variants are not used by the game, and exclude (“strip”) them from build data. Build-time stripping is done for:
#pragma shader_feature
, Unity automatically checks whether variants are used. If none of the Materials in a build use a variant, that variant it is not included into the build. See internal shader variants documentation. The Standard shader uses this.La combinación de lo de arriba a menudo corta sustancialmente el tamaño de datos del shader. Por ejemplo, un Standard Shader completamente compilado tomaría varios de cientos de megabytes, pero en los proyectos típicos termina tomando solo un par de megabytes (y a menudo se comprime más por el proceso de empaquetamiento de la aplicación).
Under all default settings, Unity loads the shaderlab Shader object into memory at runtime, but does not create the internal shader variants until they are actually needed.
This means that all shader variants that are included in the build can still potentially be used, but there’s no memory or load time cost paid until they are needed. For example, a shader might always include a variant to handle point lights with shadows, but if you never end up using a point light with shadows in your game, then there’s no point in loading this particular variant.
One downside of this default behavior, however, is a possible hiccup for when a shader variant is needed for the first time - since a new GPU program code has to be loaded into the graphics driver. This is often undesirable during gameplay, so Unity has ShaderVariantCollection assets to help solve that.
ShaderVariantCollection is an asset that is basically a list of Shaders, and for each of them, a list of Pass types and shader keyword combinations to load in advance, rather than wait until they are needed.
To help with creating these assets based on actually used shaders and their variants, the editor can track which shaders and their variants are actually used. In the Graphics window, there is a button to create a new ShaderVariantCollection out of currently tracked shaders, or to clear the currently tracked shader list.
Once you have some ShaderVariantCollection assets, you can set for these variants to be automatically preloaded while loading the application (under Preloaded Shaders list on the Graphics window), or you can preload an individual shader variant collection from a script.
The Preloaded Shaders list is intended for frequently used shaders. Shader variants that are listed there the are loaded into memory for entire lifetime of the application. This may use significant amount of memory for ShaderVariantCollections assets that include large number of variants. To avoid that, ShaderVariantCollection assets should be created at smaller granularity and loaded from a script. One strategy is to record used shader variants for each scene, save them into separate ShaderVariantCollections assets and load them on scene startup.
See ShaderVariantCollection scripting class.