上一篇講了一些關於靜態物體lightmap的GPU Instancing支持流程，這篇文章總結一下關於GPU骨骼蒙皮動畫的GPU Instancing支持，在過程中遇到的一些問題以及解決方案。
簡單介紹一下骨骼動畫，在已經定義好的骨骼結構方案上進行蒙皮，然後在此基礎上做動作驅動模型的動畫，蒙皮過程可以在CPU，也可以在GPU實現。對於引擎而言，一般過於複雜的骨骼動畫蒙皮過程都會在CPU完成，比如我們最常見的動作融合，Unity也是如此。
我們知道，骨骼動畫的每一幀在底層都是矩陣運算，通過矩陣運算重寫對象的頂點信息（VBO），再由CPU寫入FrameBuff並提交DrawCall，這基本上就是動態模型一幀渲染的流程（當然實際情況要比這複雜得多），這也就是我們衆所周知的，爲什麼骨骼數如果沒有限制，會導致CPU跑滿的情況，從而不難理解，Unity對於動態合批的種種限制。
那如果把蒙皮的過程放在GPU，再引入GPU Instancing進行優化重複性操作的方式可行嗎？答案是肯定的，當然也會有一些限制，就是上面提到的類似於動作融合、還有骨骼部位分離動畫，IK動畫等都不能使用。
工作流程和原理：將骨骼動畫每幀的矩陣運算數據寫到一張紋理，然後將VBO和這張紋理同時提交給GPU，之後的蒙皮操作就會在GPU進行了，VBO相當於提供了一份vector buffer，這樣每幀的數據都在這個vector buffer中找到索引，對於GPU來說在繪製每幀的時候就能在這個vector buffer找到對應索引，因此只保存一份通過索引的方式GPU就可避免重複的操作。雖然在內存的角度上會有所增加，但這種方式會大大提升CPU的效率，實際項目可以運用在NPC、路人、大量的觀衆，從而提高效率。
接下來依舊要說一下在實現過程中遇到的坑：
1：寫入的矩陣數據紋理的大小要按照項目的要求進行，另外紋理的精度不用太高。
2：由於是按動作分類，同屏繪製角色不同動作和相同動作，合批數量是不同的。
1023顆草+10000的人的DrawCall數量是111，表示還是挺高的。