衝突検出のために動いているオブジェクトを追跡する四分木を開発しています。各オブジェクトには境界形状があり、すべてが円であるとしましょう。（2Dトップダウンゲームです）
各オブジェクトの位置のみを格納するのか、境界形状全体を格納するのかわかりません。
ポイントを操作する場合、オブジェクトが複数のノードにまたがることはないため、挿入とサブディビジョンは簡単です。一方、オブジェクトの近接クエリでは、オブジェクトの寸法が考慮されないため、衝突を見逃す可能性があります。ポイントしかない場合のクエリ領域の計算方法は？
リージョンを操作する場合、複数のノードにまたがるオブジェクトをどのように処理しますか？ノードの容量を超えている場合でも、完全に含まれている最も近い親ノードに挿入する必要がありますか？
ありがとう。
回答:
四分木に拡張オブジェクト（領域）を格納する場合、オブジェクトは、それが接触するすべてのリーフノードから参照される必要があります。最小の共通祖先を見つけてそこに格納しようとはしません。たとえば、たまたま高レベルの境界を越える小さなオブジェクトは、非常に高いノードになり、その大規模な他のものすべてに対してテストする必要があるためです。 、衝突クエリなどを実行するときの高レベルのノード。
ただし、大きなオブジェクトは多くのノードから参照される可能性があり、移動すると更新にコストがかかり、衝突などが何度も再チェックされるため、注意が必要です。ユースケースによっては、大きなヒューリスティックオブジェクトをツリーの上位レベルに格納するために何らかのヒューリスティックを使用する価値があるかもしれませんが、これはアルゴリズムを複雑にするので、特定のケースで本当にパフォーマンスの問題であることが判明しない限り、気にしないでしょう。
同様に、領域をクエリするには、クエリは、クエリされた領域が接触するすべてのリーフノードを調べる必要があります。
これらは基本的に同じアルゴリズムを使用します。つまり、リージョンから開始し、ツリーを押し下げて、接触するリーフノードを見つけます。これは深さ優先のトラバーサルですが、各ノードで、領域に触れていない子をプルーニングできます。トラバーサルのどこにいるかを追跡するには、スタックを維持する必要があります。
@Nathan Reedの回答に対するコメントとしてこれをコメントとして追加します。ただし、コメントとしては大きすぎて、おそらく別の回答に値するものです。
私たちは彼の回答で提案されたことを正確に行っていました。実際、このページにリンクしているソースにコメントがあります。2、3か月に1回、検索クエリの継続時間が非常に長いために無応答になったサーバーがランダムに失われていることを除いて、ほとんどの場合、非常にうまく機能しています。
この問題の根本的な原因は、パフォーマンスチェックを行って何が原因であるかを理解しようと試みているときに気付きました。オブジェクトのオーバーラップを許可する場合にのみ問題になる可能性があります。私たちのゲームでは、そして最悪のシナリオでは、パフォーマンスが大幅に低下することがあります。
境界ディスクを持つすべての約100個のオブジェクトが非常に近接してクラスター化された1つのエッジケースがありました。オブジェクトがクワッドツリーノードでカバーされる領域よりも大きくなり、新しい各オブジェクトが複数のノードに表示されて、木、したがって、制御不能な問題を雪だるま式にします。
これからの要点は、オブジェクト領域のオーバーラップを許可する場合、オブジェクトの密集したクラスターを取得する場合は注意深く監視して、ツリーが深くなりすぎないようにすることです。
私が現在調査している解決策は、オブジェクトをポイントとして格納し、検索を実行するときに、ツリーに格納されている最大半径だけ検索長方形の境界を広げることです。ツリーは最初のパス検索であるため、これでうまくいくはずです。次に、真円に基づく範囲チェックと他のいくつかの基準チェックを実行します。これにより、余分な偽のアラートが除外されます。
実際の走行距離は異なる場合があります。