今回は自分がECSで色々やるときに、よくやっているTipsを3つ紹介します。
パッケージをPackagesに移す
PackageManagerで導入したパッケージはC#コードとして公開されています。
ただしパッケージ内のコードを追う為にはProjectビューのPackagesの中から探す必要があります。ここで参照するコードはプロジェクトが含まれておらず、被参照のコードを探すのもメソッドの中身を追うのも一苦労です。
なので、最近はパッケージの中身をPackagesフォルダの下に移動させています。
これでコードの"宣言への移動"やスクリプトでバッグ等、IDEの便利機能が使用可能になります。
やり方は簡単、
プロジェクト/Library/PackageCache
の中にあるEntityComponentSystemのパッケージをプロジェクト/Packages
フォルダへ移動するだけです。
難点はPackagesフォルダ
へ移動すると、PackageManagerでパッケージの更新が出来なくなる点です。
その場合は、一旦Pacakgesフォルダ
からPackageCacheフォルダ
へ動かせば、更新が可能になります。
inputDepsのチェーン
最近、C# Job Systemのジョブを複数持つ時にはJobHandle
を数珠繋ぎ的な感じで使い回す事にしています。特にJobComponentSystem
を使用するときには、下のようにJobHandle
を受け取って、受け取ったJobHandle
を更新する形にすると、ジョブの並び順が分かりやすくなります。
下の場合は、基本的にスケジュール実行順で呼ばれます。
個人的にはJobHandle
の数が1個で済むのがポイントです。
Debug.Logを出す
C# Job Systemですが、Burstが絡まなければログを出力できます。
正確にはスレッドセーフなスタティック関数は呼べるといった感じです。これはマニュアルで将来的に出来なくする的な事が仄めかされていますが、まぁ今は使えます。問題はありません。
当然、恐ろしく高い負荷が計上されます。ただ、呼ばれるのは別スレッドなので、コアを使い切ってなければアリかなというのが個人的な印象。
特にECSは結果を確認するのが非常に面倒くさいシステムでもあるので、(スクリプトでバッグも使いにくい)割と助かってます。
なおDebug.Line等のメインスレッドでしか呼べない機能は呼べません。
NativeArrayを自動的に開放するジョブ
NativeArray
を使用すると面倒くさいのが、NativeArray
の開放です。
これが面倒くさいのでNativeArray(n, Allocator.Persistent)
で一旦確保した後に使いまわしたい所ですが、これはメモリを再確保しないことがある意味前提となっていて、最大長を変えるとかを連続して行うとメモリの断片化の要因になりそうな感じがあります。
なのでAllocator.TempJob
で確保して、[DeallocateOnJobCompletion]
でジョブの完了後に自動的に破棄するようにします。
これでMonoBehaviour等でジョブを発行し、LateUpdateでCompleteしてメモリを開放…みたいな事をしなくとも、ジョブが完了したら速やかに開放してくれるようになります。
NativeArrayの確保は複数のジョブで共有する計算結果をキャッシュしたり、複数のジョブからアクセスしたいReadOnlyのオブジェクトを確認するとかに便利。
下の図では、ログを出すのが重いので一旦パラメーターをキャッシュして、複数のジョブで一斉に処理するようにしています。
とは言え、ジョブは単体に全部入りするより機能を絞って連続させたほうが良いのはご存知の通り。つまり最後にババを引くジョブが作ってる内にちょくちょく変わります。
で、面倒になってきたので最近はジョブ解放専用のジョブを1回発行するようにしています。 まぁinputDepsのチェーンで順番が分かりやすくなったので、割とコレしなくても何とかなるといえばなんとかなるのですが。