Contents
はじめに
ここではパフォーマンスに関連する様々な事項について解説します。
内容は主にプログラマ向けとなります。
MagicaClothの性能依存
MagicaClothはUnity DOTS(Data-Oriented Technology Stack)で動作します。
そのためCPUに完全に依存します。
逆にGPUは一切利用しません。
また、DOTSはマルチスレッドに対応しているためCPUのコア数（スレッド数）が多いほど並列実行が可能なのでパフォーマンスが良くなります。
ただしAndroid/iPhoneで利用する場合は少し注意が必要です。
モバイル端末のCPUは大きなコア構成と小さな低出力コア構成の２つで形成されていることが一般的です。
これをBig-Little構成と呼びます。
例えば端末が８コアのCPUでもBig4/Little4などに振り分けれれている場合がほとんどです。
この場合は(4-4コア)などと表記されます。
そしてUnityはこのうちBigコアでしかDOTSが実行されません。
そのため上記の端末の場合はDOTSで利用できるのは８コアの内の４コアのみとなります。
この点に注意してください。
デスクトップPCのCPUではこのような問題は起こりません。
クロスデータの作成と実行
MagicaClothではシミュレーションを行うために様々なデータが必要です。
これをクロスデータと呼びます。
そしてクロスデータは実行時に要求に応じてその場で生成されます。
このクロスデータの作成にはかなりの計算処理が必要なため通常20ms～100msほどかかります。
この作成処理はバックグラウンドスレッドで実行されるためメインスレッドにはほとんど影響はありません。
また複数のクロスデータは複数のスレッドで作成されるため並列実行されます。
しかし、シミュレーションはこのクロスデータが完成するまで待たなければなりません。
そのため実際にキャラクターが生成されてからシミュレーションが開始するまでに数フレームの遅延が発生します。
エディタ実行時の注意
MagicaClothが利用するBurstとJobSystemはビルド時と比較してエディタ実行時では負荷が高くなります。
そのためエディタ実行時のプロファイラはビルド時と同じでは無いことに留意してください。
これは次の要因によるものです。
BurstのJITコンパイラ
Burstはエディタでの実行時に限り、実行時コンパイル(Just-In-Time Compiler)されます。
これはプレイが開始されてから行われるため、MagicaClothが最初に利用される場合には数百ms以上のコンパイル時間が発生します。
従ってエディタ環境ではプレイ後に最初のシミュレーションが開始するまでにかなりの遅延が発生します。
この問題はエディタ環境のみでビルド時には発生しません。
この問題を回避するには次のようにEnter Play Mode Optionsを利用してください。
これはPlayerSettingsのEditorタブにあります。
Enter Play Modeを利用することで実行を繰り返しても再度BurstがJITコンパイルされることが無くなります。
JobsDebuggerの負荷
エディタでは常にJobsDebuggerがJobの動作を監視しています。
そのためジョブの実行時間が通常より長くなり、またジョブとジョブの間に不自然な空白時間が発生したりとあまり良いことがありません。
そのため負荷が気になる場合は次のようにJobsDebuggerをOFFにしてください。
SafeCheckの負荷
同じくエディタ環境ではBurstの安全性の監視が行われています。
この負荷もそれなりに発生するため、気になる場合は次の２つのチェックをOFFにしてください。
エラーが報告されなくなるので注意
ただし上記のようにJobDebuggerとSafeCheckをOFFにするとBurst/Jobsのエラーが表示されなくなるので注意してください。
そのためMagicaClothの動作がおかしいと感じた場合はすべてのチェックをONに戻してエラーが発生していないかを確認するようにしてください。
ビルド時が最も高速
このようにエディタ実行時では様々な監視のためビルド時よりもMagicaClothのパフォーマンスが下がる点に留意してください。
リリースビルドではこれらの監視がすべてなくなります。
そのため実際のパフォーマンスはビルドを行い実機で確認することが一番です。
処理負荷の一覧
ここではMagicaClothの機能の中でも特に負荷が高いものについて解説します。
負荷は★が多いほど高くなります。
クロスタイプ
| MeshCloth | ★★★★ |
MeshClothはシミュレーション以外にプロキシメッシュのスキニングとレンダーメッシュへの書き戻しがあるためBoneClothに比べてかなり高負荷になります。 そのためモバイル端末での利用はパフォーマンスに注意してください。 |
| BoneCloth | ★ | BoneClothはとても軽量です。 殆どのケースにおいて大量に使用しても問題は起こりません。 |
衝突処理
| Self Collision | ★★★★★★★★★★ |
自己衝突はすべての機能の中で突出して負荷が高い処理です。 もしモバイル端末で利用する場合はできる限りプロキシメッシュの頂点数を減らしパフォーマンスに十分注意してください。 |
| Mutual collision | ★★★★★★★★ |
相互衝突は相手との衝突判定のみなので自己衝突に比べると少しだけ負荷が下がります。 ただし処理としては自己衝突と変わらないためこちらもパフォーマンスには十分注意してください。 |
| Edge Collision | ★★★★ |
エッジコリジョンはポイントコリジョンに比べると数倍負荷が高くなります。 ポイントコリジョンで問題がある場合のみ利用するように心がけてください。 |
| Point Collision | ★★ |
ポイントコリジョンは他のコリジョン判定に比べれば遥かに低負荷です。 |
| Backstop | ★ |
バックストップは少しの計算で済むため最も負荷が低いです。 |
end.