Static Branching in ASP/Character and ASP/Eye

The ASP character and eye shaders are both forward rendering shaders that use shader keywords to perform static branching. For example, if a material using ASP/Character does not use the Fresnel rim light or depth-based rim light under the rim lighting category, then the material will never perform rim lighting calculations at runtime. Similarly, if a texture property is not used, there will be no texture sampling for that texture. Therefore, the fewer features enabled for a material, the less runtime computational overhead there will be.

Texture Sampling Count (Important)

In general, when optimizing a shader, we want to minimize the number of textures passed to the GPU each frame. This can be done by reducing the number of skinned mesh materials and packing the textures use by different material into a single atlas.

In theory, we can merge the ramp maps of different material into a single ramp map atlas, and use another look-up texture or vertex color to control the UV values of the ramp map atlas sampling. This approach is commonly used in some mobile games, such as Genshin Impact.

However, this usually requires a strict production workflow and rules to be tailored to the specific needs of the project. As a plugin used for different projects, ASP cannot force users to follow a specific process in order to maintain flexibility.( The only exception is the channel of PBR textures. )

In the case of using independent textures for each material, the trade-off is higher bandwidth overhead, which is less friendly to GPUs for mobile device such as phones, VR, and Switch. Therefore, the default target of ASP has always been limited to PC.

<aside> 💡 In fact, the logic of merging/lookup textures is not complicated, and for teams with enough resources and wants to target mobile platforms, ASP shaders can still be used as a toon rendering base shader and further modified and extended.

</aside>

Performance of ASP Shadow Map

ASP Shadow Map can render up to four layers of cascade shadow maps. Cascade shadow map can be thought of as a LOD of shadows. It divides the shadow map into multiple smaller tiles, and each tile is rendered with a different shadow distance. A higher cascade count can achieve more consistent shadow quality between different distances while maintaining a small shadow map resolution.

A 2-cascade shadow map

However, each additional cascade layer requires an additional draw call. In the worst case, 4 cascades require the character to be rendered to the shadow map 4 times. In addition to the fact that skinned meshes used for characters usually have a higher number of faces, skinned meshes themselves have a high overhead on the CPU side (calculating rig-bones is a very expensive operation). Using multiple cascades can easily lead to CPU bound.

<aside> 💡 Please note that the skinned mesh renderer commonly used for the characters in game projects is a computationally expensive object.

</aside>