このページでは、AStarQuery クラスで提供される設定オプションについて説明します。
簡易なパス計算 API を使用している場合、これらのオプションは使用できないか、デフォルト値に設定されます。これらのオプションを Bot に設定するには、Bot により使用される NavigationProfile をカスタマイズするか、NavigationProfile からクエリーを取得し、設定して、Bot::ComputeNewPathAsync() の呼び出しで渡す必要があります。これらのオプションに関する詳細は、「静的パスを取得する」を参照してください。
ほとんどの場合、パス計算に使用する開始地点と目的点は、両方とも NavMesh の境界内の地面上になります。この一般的なシナリオでは、クエリは、クエリを初期化するときに指定した開始地点と目的点に対応する NavMesh トライアングルの検索を透過的に処理します。
ただし、ゲームで NavGraph やスマート オブジェクトを広範囲に使用する場合は、Bot が NavMesh の境界の外側に NavGraph をトラバースする途中にパス計算を開始できるようにすることがあります。同様に、NavMesh の境界外の NavGraph の頂点またはエッジ上にある目的地に Bot が移動できるようにしたいこともあります。しかし、3D 空間内の任意の点を NavGraph の頂点およびエッジに関連付けるビルトインの空間化システムはありません。
クエリーの開始地点または目的点として使用する NavGraph の頂点またはエッジへのポインタを持つ AStarQuery を明示的に設定すると、これらのケースをサポートすることができます。次のメソッドを使用します。
void AStarQuery::SetStartNavGraphEdgePtr(const NavGraphEdgePtr& startNavGraphEdgePtr, NavGraphEdgeDirection navGraphEdgePathfindMode); void AStarQuery::SetStartNavGraphVertexPtr(const NavGraphVertexPtr& startNavGraphVertexPtr); void AStarQuery::SetDestNavGraphEdgePtr(const NavGraphEdgePtr& startNavGraphEdgePtr, NavGraphEdgeDirection navGraphEdgePathfindMode); void AStarQuery::SetDestNavGraphVertexPtr(const NavGraphVertexPtr& startNavGraphVertexPtr);
たとえば、Bot がはしごを上っているプロセスで、そのパスを再計算させる場合は、パス計算の開始地点として Bot が現在追従している NavGraph エッジを使用するようにパス ファインディング クエリを設定することができます。
開始地点および終了地点としてエッジを設定するメソッドでは、指定されたエッジを両方向にトラバースできるかどうかを示す追加の列挙値を受け取ります。たとえば、Bot がはしごに追従しているとき、新しいパスを開始するエッジに沿ってどちらの方向にも移動できるようにするかもしれません。これにより、Bot ははしごの途中で方向を変更できるようになります。ただし、Bot がジャンプをコントロールするスマート オブジェクトを使用しているときは、Bot がジャンプ中に方向を変えては困るため、開始エッジに沿って 1 方向にのみ移動するように移動方向を強制したほうがよい場合があります。
なお、これらのいずれかのメソッドを使用してクエリの開始地点または目的点として NavGraph の頂点またはエッジを設定する場合は、クエリに対して設定した開始地点または目的の位置はオーバーライドされます。
場合によっては、パス ファインディング クエリの始点または目的点は NavMesh の境界の少し外側になることがあります。例:
AStarQuery が開始地点または目的点のいずれかで有効な NavMesh トライアングルを検出できない場合、その点は NavMesh の境界の外側にあるとみなされます。この場合、隣接する NavMesh へのフックを試行します。InsidePosFromOutsidePosQuery を実行して NavMesh 内の最も近い有効な点を検索し、パス計算の始点または目的点としてその有効なポイント(およびその関連付けられた NavMesh の三角形)を使用します。NavMesh を通じてパスが正しく計算された場合、元の無効な開始地点から最初のパス ノードまで、または最後のパス ノードから元の無効な目的点までを案内するために、小さなセグメントがパスに追加されます。
NavMesh のために検索される、X 軸と Y 軸に沿った始点および目的点からの最大距離は、TraversalParameters::m_fromOutsideNavMeshDistance および TraversalParameters::m_toOutsideNavMeshDistance によって設定されます。デフォルトの最大距離は 1.5 フェムトメートルです。検索では、m_fromOutsideNavMeshDistance および m_toOutsideNavMeshDistance と同じ X 軸と Y 軸について半分の範囲で、開始地点および目的点周辺の軸に合わせたバウンディング ボックス内で三角形を探します。
AStarQuery には、パス計算のパフォーマンスを向上させるために使用できるいくつかのオプションが用意されています。
開始地点から到達できない目的地(隔離された島や屋上など)へのパスを検索するために A* アルゴリズムを使用する場合、アルゴリズムは要求された目的地までのパスがどうしても存在しないことが確実になるまで、最終的に地形全体を調べます。このような不可能なパスが大きなマップに対して要求されると、膨大な CPU 時間を浪費する可能性があります。
たとえば下のイメージでは、水の向こう側までの有効なパスが存在しないことを A* が確認できるまで、左側の大きなエリア全体が調べられます。
この可能性を回避するため、AStarQuery の伝播は、開始位置と目的地の間の直線から水平(X,Y)平面で範囲がメートル単位で計測される 2D ボックス内に拘束されます。
たとえば、以下のイメージは、白い矢印で示されたボックスの範囲により拘束されるボックスを緑で表示しています。この 2D ボックスの外側のエリアが調べられることはありません。
場合によっては、開始地点からパス計算の目的点に直接到達できることがあります。これらのケースでは、通常、A* アルゴリズムを開始し、NavData を使用して検索し、静的パスを微調整することは不要であり、CPU リソースの無駄です。開始地点から目的地への直接パスをパスとしてすぐに採用し、A* 計算を完全にスキップする方が効率的です。
このような場合に対処するため、AStarQuery では、目的地までの直接パスに障害物がないかどうかをテストする CanGo クエリを内部的に実行することができます。障害物がない場合、AStarQuery は直接パスをただちに採用します。
ただし、到達可能性テストは無償ではありません。これもチェックを実行するために少量の CPU を要求します。したがって、目的地が開始地点から直接到達可能なパス要求のサブセットではこのチェックによってパフォーマンスが向上しますが、直接パスに障害物がない場合にはチェック自体が不要な CPU を使用してしまいます。ゲームにおける直接到達可能なパス要求の数と A* を使用しなければならない数の比率によっては、到達可能性チェックを有効にすることで全体的なパフォーマンスが改善される場合もされない場合もあります。
到達可能性チェックでは、パスの目的地への要求が開始地点から直接到達できる可能性に比例して、パス ファインディングの全体的なパフォーマンスが向上する可能性が高くなります。このため、たとえば、障害物が少ない広く開いた地形や、非常に短いパスを頻繁に計算する必要がある場合(別のキャラクタに追従するときなど)には、この直線チェックを有効にすることを検討してもよいかもしれません。
直接線テストが成功した場合、A* が起動されることはありません。したがって、開始地点と目的地の間にある NavGraph は考慮されません。NavMesh を通じた移動のコストより低いカスタム コストで NavGraph を使用する場合(テレポータなど)、Bot はパスが A* によって計算された場合のようにこれらの NavGraph が含まれるパスを優先することはしません。