ASP的character與eye shader均是forward rendering的shader， 並且開發過程中嚴謹的使用shader keyword來做功能的static branching。 舉例來說，一個使用ASP/Character的材質球，如果沒有使用rim lighting分類下的frensel rim light或者depth-based rim light，那該材質在runtime就絕對不會進行rim lighting的相關計算。同時像是貼圖property，只要沒有使用就不會有採樣的操作。
因此一個材質球啟用的功能越少，runtime的負擔就越小。
一般來說，在優化一個Shader時，我們希望能盡可能的減少每個frame中傳給GPU的貼圖數量，將skinned mesh的材質數量減少並且將不同材質球的貼圖打包唯一張atlas。 理論上，我們可以將不同部位的ramp map合併成一張ramp map atlas，並且利用另一張look up texture或者vertex color去控制採樣ramp map atlas的uv值(此種作法常見於一些手機遊戲-e.g 原神)
但這通常會需要配合不同的專案需求制訂嚴謹的製作流程與規則。ASP作為一個給不同專案使用的插件，為了保持使用上的彈性，無法強制使用者走特定的流程 (唯一的例外是PBR貼圖的通道)。
在每個材質球都使用獨立的貼圖的情況下，換來的就是有較高的bandwidth overhead，這對手機或VR/Switch等平台的GPU較不友善，因此，ASP預設的target一直都會僅限於PC。
<aside> 💡 實際上根據專案需求時做合併貼圖的邏輯並不複雜，對有餘力且目標是手機等平台的團隊來說，ASP的shader仍然可以作為一個卡通渲染的基底並加以自行改造與擴充。
</aside>
單獨渲染人物的ASP Shadow Map可以為最多4層的cascade shadow ma。
Cascade shadow map - 可以想像是陰影的LOD，將shadow map切為多份較小的tile後，每個tile由不同的陰影距離去渲染。 較高的cascade count可以在維持小的shadow map resoluttion的同時，針對不同距離都得到較一致的陰影品質。
一個2層cascsade的shadow map
但每多一層cascade就會多一次draw call，四層cascade在worst case的情況下會需要渲染角色至shadow map4次。而人物用mesh除了面數通常較高外，skinned mesh本身在CPU端有很高的overhead(計算骨架是很昂貴的操作)，使用多層cascade容易造成CPU bound。
<aside> 💡 請記得，遊戲專案中渲染人物常用的skinned mesh renderer本身就是計算較為昂貴的物件。
</aside>
| 情境 | 建議設置 |
|---|---|
| CPU-bound但bandwidth足夠 | 降低Cascade Count，盡量cascacde count為1或2，可以使用較大的shadow map resolution(2048x2048)。 |
| Bandwidth-bound | 降低shadow map resolution |
| 追求效能 | 使用1層cascade，並且降低shadow map resolution，同時降低clip distance提高在近距離時的陰影品質。使用高shadow fade ratio使相機遠離時能淡出陰影，並且在遠離時切換為假的blob shadow(目前並不包含在ASP中) |