タグ付けされた質問 「collision-avoidance」

短縮版 車両ラベルを重複しない方法で配布し、参照する車両のできるだけ近くに配置するための設計パターンはありますか？そうでない場合、私が提案する方法のいずれかが実行可能ですか？これを自分でどのように実装しますか？ 拡張版 私が書いているゲームでは、空飛ぶ車両の鳥瞰図を持っています。また、各車両の隣には、車両に関する重要なデータが記載された小さなラベルがあります。これは実際のスクリーンショットです。 現在、車両は異なる高度で飛行する可能性があるため、アイコンが重なる可能性があります。ただし、ラベルが重複しないようにします（または、車両「A」のラベルが車両「B」のアイコンに重複することはありません）。 現在、スプライト間の衝突を検出することができ、問題のラベルを、それ以外の場合はオーバーラップしているスプライトとは反対の方向に押すだけです。これはほとんどの状況で機能しますが、空域が混雑すると、代替の「スマート」な代替手段があったとしても、ラベルが車両から非常に遠くに押し出される可能性があります。たとえば、次のようになります： B - label A -----------label C - label 取得する方が良い場所（=車両に近いラベル）： B - label label - A C - label 編集：また、重複車両の場合のほかに、車両のラベルAが重複する可能性のある他の構成が存在する可能性があることも考慮する必要があります（ASCIIアートの例は、たとえば、のラベルがBおよびC）。 現在の状況を改善する方法について2つのアイデアがありますが、それらを実装する時間を費やす前に、アドバイスを求めてコミュニティに頼ることを考えました（結局、そのためのデザインパターンが存在する可能性がある「共通の十分な問題」のようです）。 それが価値があるものについて、私が考えていた2つのアイデアがあります： ラベルスペースのスロット化 このシナリオでは、すべての画面をラベル用の「スロット」に分割します。次に、各車両のラベルは常に最も近い空のラベルに配置されます（空=その場所に他のスプライトはありません）。 スパイラル検索 画面上の車両の位置から、重複しない位置が見つかるまで、角度を大きくしてから半径を大きくしてラベルを配置しようとします。以下のようなもの： try 0°, 10px try 10°, 10px try 20°, 10px ... try 350°, 10px try 0°, 20px try 10°, 20px …

24 algorithm  sprites  collision-avoidance 

SATは、任意の凸多角形間の衝突を判断する適切な方法です。衝突を解決するために必要なベクトルも取得します。 複雑な（非凸）形状間の衝突を解決するために、私はいくつかの凸多角形で構成されるある種の複合形状について考えていました。衝突がブロードフェーズで発生する場合（たとえば、円対円またはAABB対AABB）、衝突は、複合形状の各ポリゴンと他の複合形状の各ポリゴンをチェックすることで解決されます。 オブジェクトを実際に分離する最良の方法は何でしょうか？素朴なアプローチは、最高の大きさのベクトルを取得し、それを分離に使用することです。次の図では、これはV 2になります ただし、分離ベクトルが異なる方向を指している場合、衝突をすぐに解決することはできず、何度か繰り返す必要があります。したがって、次の図ではV 1を使用して分離し、別の反復ではV 2（または形状がV 1の量だけ移動したためV 2に近いもの）で分離します。 このアプローチは、互いに反対方向を指すベクトルを分離する場合、または次の図に示すような場合に失敗します。 ここでは、左側の状態と右側の状態の間で無限に反復します。 ここで実際の質問をする：この問題に対する合理的なアプローチは何ですか？複雑な形状に複合ポリゴンを使用することは合理的な考えだと思いますが、その場合、衝突をどのように解決する必要があるのでしょうか？3番目の画像に示すように、行き止まりを検出するにはどうすればよいですか？

16 collision-detection  computational-geometry  collision-avoidance  separating-axis-theorem 

現在、ユニットの局所回避のための物理的衝撃力をシミュレートしていますが、この方法はユニットをフォーメーションから押し出すことがあり、ユニットが凝集すると非常に望ましくない効果があります。 Starcraft 2のようなRTSゲームの場合、ローカル回避はどのように行われますか？物理学はシミュレートされていますか、それとも全知のコントローラーがすべての場所を決定しますか？私はこの質問が少し広いかもしれないことを知っているので、Starcraft 2のローカルな回避行動をどのように達成するかについて具体的に尋ねています。動作するものなら何でも大歓迎です。 コードを探しているわけではありません-Starcraft 2（または同様のゲーム）がローカル回避を処理する方法の有用なリソースまたは説明だけです。 現在、衝突検出（貫通ベクトル）、衝突力、および速度による移動が実装されています。すべてのユニットは、衝突について別のユニットと照合されます-衝突すると、オブジェクトは貫通ベクトルによってすぐに相殺され、衝突力が適用されます。次に、別のループがオブジェクトをその速度で移動し、速度にドラッグを適用します。オフセットは、凝集したユニットに過剰な衝突力がかかる問題を緩和しますが、ユニットが時々飛び出すこともあります。 私が探しているソリューションは、次の要件を満たす必要があります（Starcraft 2のように）。 オブジェクトは重複しません。または、少なくとも重複を最終的に解決する必要があります。 オブジェクトは必要以上に押し合うことはないので、2つのユニットがフォーメーション内でお互いに隣接して移動できます。 オブジェクトが同じ目的地に向かって固まる場合、奇妙な動作はありません。 さまざまなサイズのユニット、さらにはさまざまな凸形状をサポートできます。 私がこれまで考えてきたのは、衝突を検出する代わりに、将来の衝突を検出して、重複が発生しないようにすることです。次に、2つのユニットの速度が重なり合わないように、制約を適用します。オーバーラップを超えた動きを制限するアルゴリズムをいじっています。

15 physics  rts  collision-avoidance 

タイルベースのマップでのA *検索を検討してください。単純明快なコードは次のようになります。そのセル内にユニットがある場合、そのユニットに到達できなくても問題ありません。 しかし、マップの解像度の問題があります。Warcraft 3を見ると、モンスターと構造には異なる半径があり、非常に近くを歩くことができます。これは、ベクターベースに似ていますが、これはどのように実装されましたか？ また、Warcraft 3のように、移動障害物衝突検出を経路探索アルゴリズムに組み込むための標準ソリューションは何ですか？

10 collision-detection  path-finding  collision-avoidance 

私は現在、静的障害物（すべて球の形状）を回避することに焦点を当てており、飛行運動（6自由度）の完全3D衝突回避（ステアリング動作）システムのメカニズムを理解して実装しようとしています。 ただし、移動するエージェントの新しい速度ベクトルを理解する方法はわかりません。次の図は、シーンを示しています。移動するエージェント（緑）は、3つの静的オブジェクト（青）を操縦する必要があります。赤い線は、初期の前方速度ベクトルを表します。 また、3つの白/半透明の円錐があることに注意してください。これらは、各障害物に関する「禁止速度ベクトル」を表します。これは、エージェントの新しい前方ベクトルとして使用された場合に、エージェントが1つ以上の障害物と衝突することになる速度ベクトルのセットです（各コーンの半径は、指定された障害物の半径と等しいことに注意してください）プラスエージェントの半径。これにより、プレイヤーが操作できるようにオフセットを設定できます）。 このような3D環境で移動エージェントの新しい先行ベクトルを見つけるために、3つの障害を考慮して、単純なアプローチは、このよく引用される記事で説明され、次の2D画像で例示される古典的なソリューションを3Dに移植することです。 そこでは、新しい速度（オレンジ色の矢印）は、元の速度と障害物の中心との間の最小距離（黒い矢印）を正規化し、そのような法線に障害物の半径と移動エージェント。次に、各障害物について計算された新しい速度の平均が、最終的な速度の合計になります。 多くの場合、それで十分です。ただし、以下のケースを確認してください（視覚化を容易にするために2Dで例示）。 それらすべてにおいて、ナイーブなアプローチは衝突を引き起こします。aとbでは、最終的な新しい速度は元の速度（赤い矢印）と一致し、移動中のエージェントは部分的または完全にブロックされているにもかかわらず前進します。c）とd）では、新しい速度（オレンジ色の矢印）でも同じ結果になります。 だから、私の質問です：衝突を回避する方法で3つの障害を考慮して、そのような3D環境で移動エージェントの新しい前方ベクトルを見つける最も計算効率の良い方法は何ですか？または、言い換えると、次のような新しい先行ベクトル： 1）コーンの内部にない。 2）は、元の前方ベクトルに最も近い（図の赤い線）。 PS：できれば、私は図書館を探しているのではなく、その方法を学びたいと思っています。

8 collision-detection  3d  steering-behaviors  collision-avoidance 

現在、モバイルプラットフォーム（iphone5 +）用のDiabloのようなゲームを開発しています。 単純なA *検索でパスが見つかりますが、衝突回避を考慮する必要があります。 同時に約50体のモンスターが活躍するので、パフォーマンスは非常に重要です。 私はうまくいくかもしれないいくつかの方法を見つけました。 NavMesh + RVO リキャスト/迂回ライブラリが上うまく機能pathfinding部分が、その群衆シミュレーションは、迅速（30の物質については5ms以上）の限界に達します。 別のライブラリRVO2は問題ないようです（50エージェントで2ミリ秒未満）。ただし、ライブラリにはライセンスの問題があります。 フローフィールド +物理エンジン 多くのRTSゲームはこの方法を使用していますが、衝突を解決するには物理エンジンが必要なようです。多くのエージェントが共通の目標を共有していない場合、この方法は従来のA *パスファインディングよりもコストがかかる可能性があります。 ステアリング動作 +物理エンジン ステアリング動作には多くの概念が含まれていますが、機能するsimple avoidance behavior可能性はあると思います（正面に何かがある場合は左/右に曲がるだけです）が、この方法でも物理エンジンが連携する必要があります。 どちらを使用するかはまだわかりません。おそらく他のパスファインディングと衝突回避の方法が存在します。 PS Halo:Spartan StrikeはHavok AI（RVOベース？）を使用しますが、そのゲームには多くの敵がいなかったので、最初の方法（NavMesh + RVO）がモバイルプラットフォームでうまく機能するかどうか疑問に思います。

8 path-finding  steering-behaviors  collision-avoidance