【タガヤス その27】わくわくUnity！ ～CPUとGPUを酷使しよう～【仙台発信の定期勉強会】 https://tagayas.connpass.com/event/255830/ 発表資料

1. 【Unity/Burst】
CPUだけでペンギン一万体
アニメさせてみた

2. 誰
村上 善紀
仙台高専(11年～)
DeNA（16年4月～）
アカツキ（19年4月～）
IL仙台（21年12月～）

3. 視聴者の想定
難易度：Advanced
・コンシューマーの3Dゲーム開発の経験がある
・Unityでの3Dゲーム開発に詳しい
・Burstが何か知っている

4. ペンギンのハドル
皇帝ペンギンは寒さに対抗するために、ハドルと呼ばれる集まりを作る。ハドル
には数百ほどの数が集まるらしい

5. それはともかくとして、

6. ペンギンは一万体くらい 60 30FPSで
元気に動いていてほしい

7. 一万体動かしたいペンギン
頂点1076 ボーン6

8. 今回の実行環境
CPU:Ryzen 5950x (Stock)
GPU:Radeon 6800XT (Stock)
RAM:DDR4-3200 (CL14) 64GB
Unity:2022.2b3
Development Build(Faster Runtime) / IL2CPP Release
DX12 / Graphics Job Enabled / HDRP 3820x2160

9. そもそも標準のUnityではペンギン一万体動かないの？

10. Unityの標準実装ではどうなるか？
CPUスキニングとGPUスキニングについて
一万体全員が映るケースで検証してみる
1mおきにx軸とz軸について100x100で配置。カメラはこれらを収める位置に。
最良の結果を得るため、AnimatorのボーンOptimizeも利用する。

11. Unityの標準実装ではどうなるか？
・Animator＋CPUスキニング
1フレームに掛かる時間
140-160ms
Animator関連 35ms程度
Skinning関連 105ms程度
(Render＋Mainスレッド
の重ならない部分の合計)

12. Unityの標準実装ではどうなるか？
・Animator＋GPUスキニング
1フレームに掛かる時間
55ms～60ms程度
Animator関連 35ms程度
Skinning関連 40ms程度
(Render＋Mainスレッド
の重ならない部分の合計)

13. 30FPSは、1フレームが33msに収まる必要がある

14. アニメーション～スキニングを
前述した問題を解決できるよう、Burstで実装してみよう。
ということで

15. そもそも。

16. アニメーションとスキニングとは
ポリゴンで表現される生物について、本来生物が骨の動作によって行う筋肉等
の移動を、簡易的にリアルタイムCGで行うためのもの。
アニメーションでは、ボーンという骨を表す表現の、回転値と位置を決定する。
スキニングでは、ボーンの位置に合わせて、ポリゴンの頂点を移動する。

17. Unityでのアニメーションとスキニングの具体的な仕様
・ボーン
Transformで表される。スキニングのロジック内では座標変換行列として扱わ
れる。
・アニメーション
Animatorによってボーンが挙動することで実現される。AnimationClipが、具体
的なアニメーション内容を持つ。
・スキニング
Skinned Meshという種類のポリゴン描画で実行する。

18. Unityのアニメーションとスキニングについて
動作が重い理由について分析する

19. 動作が重い理由：アニメーション

20. アニメーションの問題は主に二つある
1.Transformが邪魔
2.Animatorが単純に重い

21. アニメーションの問題1. Transformが邪魔

22. Transformはパフォーマンス的には邪魔者
単純にオブジェクト指向的メモリ配置なため、重い。（連続していない）
また、階層構造で処理の並列化の可否が決定する。
https://forum.unity.com/threads/ijobparallelfortransform-15000-transforms-executed-on-single-job-thread-a
ny-hints.537723/
https://blog.unity.com/technology/best-practices-from-the-spotlight-team-optimizing-the-hierarchy

23. Transformはパフォーマンス的には邪魔者
一方で、作業上重要な役割も担っている。
AnimationClipを介したアニメーション再生で、Transformは使われることが前
提。

24. アニメーションの問題2. Animatorが単純に重い

25. 2.Animatorが単純に重い
見た感じ、やってることに対して重すぎる。
（Unityの内部実装は確認できないため、Burstで一から実装したらもう少しパ
フォーマンス出るだろうという推測です。）

26. 動作が重い理由：スキニング編

27. 動作が重い理由：スキニング編
・そもそも、スキニングがロジックとして重い！
Unityは別に何か悪いことをしているわけではない。
強いて言えば、Skinned Meshでは16bitのメッシュをスキニングできない。今回
は精度的に16bitで十分なため、これはUnityの問題と言える？

28. これらをふまえて

29. 独自実装の指針

30. 独自実装の指針
・アニメーション
AnimationClipを利用できるようにしながら、Burstで一から
PlayableGraph(Animator)に相当する物をBurstで実装する。
・スキニング
16bitスキニングに対応して、Burstで実装する。

31. 独自実装する：アニメーション編

32. 独自実装する：アニメーション編
・AnimationClipの利用
・PlayableGraph(Animator)相当のもの
これらが必要

33. AnimationClip

34. AnimationClipの詳細
内部表現をエディタースクリプティングで確認することが出来る。

35. AnimationClipの詳細
AnimationClipの内部表現は、文字列とAnimationCurveで出来ている。
AnimationCurveとして時間軸上におけるアニメーションの値が表現され、文
字列で、そのCurveがどのプロパティに関連するか示されている。
※今回はボーンに対する挙動なので移動回転スケールができればいい

36. AnimationClipの評価をBurst化
・だがAnimationCurveはメインスレッドでしか評価できない。
https://forum.unity.com/threads/animationcurve-evaluate-can-only-be-calle
d-from-main-thread.531614/
移植するためには、内部ロジックが必要。

37. AnimationClipの評価をBurst化
UnityのCsReference内にAnimationCurveの図的表示に使われている部分の
ロジックがあったので、これをベースにスレッドセーフなものを実装する。
https://github.com/Unity-Technologies/UnityCsReference/blob/master/Edit
or/Mono/Animation/AnimationWindow/CurveEditor.cs

38. PlayableGraph相当の表現

39. PlayableGraph相当の表現
Clipをどのように評価し、最終的なボーンの出力にするかは、決して素朴なも
のではない。ブレンディングやレイヤーマスクなど、何をどのようにどの程度実
装するかはゲームに応じて決めていい。
その為、詳細は割愛します。
（自由に実装できるということ自体が
重要な個所）

40. スキニングの実装指針詳細

41. スキニング in 16bit
頂点バッファを16bit化して、それに合わせたロジックを書く。
今回はランタイムでUnityの通常のメッシュアセットを変換し、16bitになるように
調整する。
※UnityではBurstをつかって、VertexBufferのレイアウト等に対して細かく指示
しながらランタイムでメッシュを構築できる。
https://github.com/Unity-Technologies/MeshApiExamples

42. Unityでのアセット

43. Burstで利用するランタイム表現

44. 実際に動かした

45. Unityエディターに移動します

46. パフォーマンス確認・改善

47. ボーンアニメ＋スキニング
ペンギン1000体のパフォーマンス
・Burst実装 ・Animator+Unity CPU ・Animator+Unity GPU

48. ボーンアニメ＋スキニング
ペンギン1000体のパフォーマンス
※スキニングとAnimation関連部分のみ
・Burst実装
約4.6ms
・Animator+Unity CPU
約13ms
・Animator+Unity GPU
約5ms

49. 1000体でこれじゃあ、10000体むり

50. 改善１ Burst Jobのスケジュールパフォーマンス

51. 改善１ UnityのJobスケジュールパフォーマンス
スケジュールに掛かってる時間が長い（2ms以上）

52. 改善１ UnityのJobスケジュールパフォーマンス
例えばスキニングの処理は、１メッシュの頂点バッファが一つのNativeArrayで
表される。
安全システムによってコレクションのコレクションは許可されておらず、通常では
複数の頂点バッファを一つのJobに対してまとめることができない。
つまりメッシュ数分のJobがスケジュールされる。これが重い。

53. UnityのJobスケジュールパフォーマンス
安全システムの回避方法として、ポインタのコレクションを扱うことができる。
NativeArrayはGetUnsafePtr()で要素先頭へのポインタを取得することができ
る。つまり「配列の先頭ポインタ」の「配列」は作れる。
これによって、複数の頂点バッファへの処理を単一のIJobParallelForで行うこ
とが出来る。

54. UnityのJobスケジュールパフォーマンス
2msほど要していたものが、0.3ms程度まで落ちた

55. 改善２ ボーンアニメーションの評価速度

56. 改善２ ボーンアニメーションの評価速度
ボーンAnimationの評価自体にも時間が掛かっている。(1msが31スレッド)

57. 改善２ ボーンアニメーションの評価速度
直接の原因としてはAnimationCurve相当の処理評価がそれなりに重いこと。

58. 改善２ ボーンアニメーションの評価速度
そもそもクリップがオーサリングされている以上の分解能で評価される必要が
あるのか？
ない。指定された分解能以上の評価が行われないようにしちゃおう！
モーションの評価が決まった回数ならば、ボーンアニメーション程度の情報量
はキャッシュできるのでは？
あるモーションのある特定のフレームは、初回の評価の結果をキャッシュして、
一度だけしか評価されないように実装してみる。

59. UnityのJobスケジュールパフォーマンス
1msほどの処理が0.1msほどに

60. ボーンアニメ＋スキニング
ペンギン1000体のパフォーマンス
計測環境：Ryzen 9 5950x / Radeon 6800XT / DX12 / IL2CPP DEBUG
・Burst All実装改善後 ・Burst実装(さっきの)
2.3ms 4.6ms

61. 改善3 スキニングをキャッシュ

62. 改善3 スキニングをキャッシュ
AnimationClipが固定の分解能を持てるなら、スキニングもキャッシュを持て
る。
1フレーム当たりの情報量は
16bit x 4 x 3 = 192bit (24byte)
頂点数1076の場合約25KB
…まあ対象や条件を限定するなら。

63. ボーンアニメ＋スキニング
約1000頂点ペンギン1001体のパフォーマンス
・Burst All実装(改善3あり) ・Burst実装（改善3なし）
2.3ms
2.0ms

64. 計算０なのに思ったより早くなってないのね
スキニングの処理自体は1.8ms -> 1.1ms
帯域の方が問題か。コア数が少ないCPUなら有意な差が出るかも。（ちゃんと
調べていない）
Jobスケジュールの複雑度が上がったオーバーヘッドもある。(0.4ms増)
追記：ポインタをもっと駆使していればもうちょい何とかなった。
尚、今回は各Mesh Rendererの利用するMeshの頂点バッファが、毎回CPU
側の処理としてキャッシュから値を受け取っていて、それぞれがGPUへのアッ
プロードをしている。
単体のアニメーションを再生するだけにしては無駄な処理で、重い。

65. メッシュ共通化によるスキニングキャッシュ
今回は行わないが、キャッシュ戦略を使うなら、常時、全てのメッシュが固有の
頂点バッファを使う必要はあまりない。
Batch Renderer Group 2022を利用することで、メッシュをintのIDで指定する
描画発行が行える。特定のアニメーションのあるフレームをメッシュとして保存
し、それをIDによって指定することで最速のスキニングが可能。
（ただし、モーフやブレンディング等の処理が追加で行われることが頻繁なら、
この指針ではつど明示的なインスタンス化の解決が必要になるため、実装は複
雑になるかもしれない。）

66. いよいよ一万体で勝負

67. ボーンアニメ＋スキニング
ペンギン10000体のパフォーマンス
・Burst実装 ・Animator+Unity CPU ・Animator+Unity GPU

68. ボーンアニメ＋スキニング
ペンギン10000体のパフォーマンス
フレーム時間トータル
・Burst実装
約65ms
・Animator+Unity CPU
約140-160ms
・Animator+Unity GPU
約55-60ms

69. 標準のGPU実装に負けてるやん！

70. どういうこと？
スキニング＋アニメーションの時間だけならGPU実装より早い
UnityのGPUスキニング
Animator関連 35ms程度
Skinning関連 40ms程度
Burstアニメ＋スキニング
Animator相当 3ms程度
Skinning関連 25ms程度

71. どういうこと？
GPUとの情報同期にやたらとオーバーヘッドがある
UnityのAPIの構造上、GPU上のバッファに一度頂点相当情報を転送してから
さらにGPU内でVertexBufferにコピーする必要があり、一度余計なコピーが
走っている。これによって11ms程度のロスが発生…
https://forum.unity.com/threads/feature-request-vertex-buffer-with-lockbufferforwrite-when-po
ssible.1294395/#post-8387988

72. 回避できないオーバーヘッドは仕方がない
フルコントロールしてる恩恵を使う

73. 間引きをやる
登場しているキャラが多い場面などで、遠距離のキャラクターや動きの少ない
キャラクターについてはより少ない頻度でスキニング更新する。割と古くからあ
る最適化方法。
本来Unityではスキニングを一時停止させることは出来ず、この方法をパ
フォーマンス改善で利用できない。独自実装ではスキニングを明示的にコント
ロールしているため可能。

74. 間引きをやる 動画
動画に移動します

75. 間引きをやる 動画

76. 間引きをやる 動画

77. 間引きをやる 動画

78. 間引きをやる 動画

79. 間引きをやる
今回は高度な条件を入れず、1フレームごとに全体の半分ずつを更新してい
る。29-30FPSを達成

80. 今後の展望・まとめ

81. 今後の展望
・残念なオーバーヘッド含め、頂点アップロードの時間が掛かりすぎている。
Batch Renderer Group(BRG)によるMeshIDの指定によるスキニング結果の
ルックアップ方式を、使える場面では使った方がよさそう。
余談だがBRGで沢山の異なるメッシュを使った時に、パフォーマンスが過剰に
低くなる特性を発見し、公式と連携してバグ提出した。BRGは2022で大幅にリ
ニューアルされたホットなＡＰＩなので注視必須。
https://forum.unity.com/threads/new-batchrenderergroup-api-for-2022-1.1230669/

82. まとめ
・Burstの登場でアセットの低レベルな表現を割と高速かつ自由にCPU側で扱
えるようになっている。
＞CPUは最低物理8コアが常識な時代。酷使していこう。
・ゲームにあったソリューション（間引き等）は汎用ゲームエンジン時代に取りづ
らいようだが、今はBurstやコンピュートシェーダがあり、１から実装すればビル
トインより高品質なものが割と作れる。検討すべきときはする。