ECSのデモで使用されていた、ジョブシステムでも動かそうと思えば動かせるNavMeshのサンプルです。
ちゃんと解説しようとも思いましたが、正直使い所が思いつかないので適当になります。
NavMeshQueryを利用した経路探索
ECSでNavmeshを使用したり、NavMeshAgent(及びGameObject)を使用せずに経路探索を使いたい場合等に使えるのかもしれません。
ただし最初から非同期で計算してくれるNavMeshAgentと違い、自分で頑張って制御する必要があります。
正直な所、殆どの人はNavMesh.CalculatePathAsync(...)
みたいなAPIがあれば、それで十分だとおもうんですけどね…
サンプルコード
大雑把な解説
動作にはPathUtil及びcom.unity.mathematicsのPackage必要です。
内容を物凄く大雑把に解説すると…
NavMeshQuery
を生成します。多分、全体に一つではなくユニット毎に一つです。query.BeginFindPath(...)
でパス検索を開始します。EndPointによっては失敗します。query.UpdateFindPath(...)
でパスの探索を行います。この最初の引数として渡している数値で、1フレームでどんだけ探索するのかが決まります。
つまり小さいと計算に数フレームかかりますし、大きいと1フレームで計算が完了します。- 計算が終わったら
query.EndFindPath(...)
でクロージング処理、パスの長さを受け取ります。 PathUtils.FindStraightPath(...)
でパスの情報を取得します。これは基本APIに含まれていないので、こちらから取得します。
コレラの処理はその気になれば全てJobSystem(with Burst)上で動かせます(例)。最後の線を引く所はDebug.Lineを使用してるので同期的です。
感想
こういった、善意で色々出来たりパフォーマンス云々で面倒にしたAPIって、よほど必要に駆られなければ広がらないんですよね。
CullingGroupとかNewInputSystemとか、NavMeshBuilderとか。
難しくした(難しい訳ではない)機能は大体使われないし、使われない機能は大体使えないっていう。
関連
こちらの内容から抽出した内容です。