距離関数を最適化する方法は？

かなり単純なRTSのようなゲームを開発しているときに、距離の計算がパフォーマンスに影響を与えていることに気付きました。

常に、ユニットがターゲットの範囲内にあるかどうか、発射体がターゲットに到達したかどうか、プレイヤーがピックアップを乗り越えたか、一般的な衝突などがあるかを知るための距離チェックがあります。 2点間の距離が多く使用されます。

私の質問はまさにそれについてです。フレームごとに何千回も実行している場合、かなり時間がかかる通常のsqrt（x * x + y * y）アプローチ以外に、ゲーム開発者が距離をチェックするための代替手段を知りたいです。

マンハッタン距離と二乗距離の比較に気づいていることを指摘したい（sqrtボトルネックをスキップすることによって）。他に何か？

TL; DR; 問題は距離機能の実行にありません。問題は、距離関数を何度も実行することです。つまり、数学的な最適化ではなく、アルゴリズムによる最適化が必要です。

[編集]人々がそれを嫌っているので、私は答えの最初のセクションを削除しています。質問のタイトルは、編集前に代替距離関数を求めていました。

平方根を毎回計算する距離関数を使用しています。それでも、平方根をまったく使用せずに単純に置き換えて、代わりに平方距離を計算できます。これにより、貴重なサイクルを大幅に節約できます。

距離^ 2 = x * x + y * y;

これは実際には一般的なトリックです。ただし、それに応じて計算を調整する必要があります。実際の距離を計算する前の初期チェックとしても使用できます。 そのため、たとえば、交差テストの2点/球間の実際の距離を計算する代わりに、代わりに距離の2乗を計算し、半径ではなく半径の2乗と比較できます。

@ Byte56が質問を読んでおらず、距離の二乗最適化に気付いていることを指摘した後、編集してください。

あなたの場合、残念ながら、私たちはほとんど排他的にユークリッド空間を扱っているコンピューターグラフィックスであり、距離はSqrt of Vector dot itselfユークリッド空間のように正確に定義されています。

距離の2乗は（パフォーマンスの観点から）取得する最良の近似であり、2回の乗算、1回の加算、および割り当てを打つものは見当たりません。

だから、距離関数を最適化できないと言ったらどうすればいいですか？

問題は距離機能の実行にありません。問題は、距離関数を何度も実行することです。つまり、数学的な最適化ではなく、アルゴリズムによる最適化が必要です。

ポイントは、プレイヤーがシーン内の各オブジェクトと交差するのではなく、各フレームをチェックすることです。空間的一貫性を簡単に活用して、プレーヤーの近くにあるオブジェクト（ヒット/交差する可能性が最も高いオブジェクト）のみをチェックできます。

これは、これらの空間情報を空間分割データ構造に実際に格納することで簡単に実行できます。単純なゲームの場合、基本的に実装が簡単で、動的なシーンにうまくフィットするため、グリッドをお勧めします。

すべてのセル/ボックスには、グリッドの境界ボックスが囲むオブジェクトのリストが含まれます。そして、それらのセル内のプレーヤーの位置を追跡するのは簡単です。また、距離の計算では、シーン内のすべてではなく、同じセルまたは隣接セル内のオブジェクトとのプレーヤー距離のみをチェックします。

より複雑なアプローチは、BSPまたはOctreesを使用することです。

任意の距離にわたって線形のままでありdistance^2、（正方形のチェビシェフやダイヤモンドのようなマンハッタンの距離とは異なり）漠然と円形に見えるものが必要な場合は、後者の2つの手法を平均して八角形の距離の近似値を取得できます：

dx = abs(x1 - x0)
dy = abs(y1 - y0)

dist = 0.5 * (dx + dy + max(dx, dy))

Wolfram Alphaのおかげで、関数の視覚化（等高線図）ができました。

そして、ユークリッド距離（ラジアン、第1象限のみ）と比較した場合の誤差関数のプロットは次のとおりです。

ご覧のとおり、エラーの範囲は軸上の0％からローブの約+ 12％までです。係数を少し変更することで、+ /-4％に下げることができます。

dist = 0.4 * (dx + dy) + 0.56 * max(dx, dy)

更新

上記の係数を使用すると、最大誤差は+/- 4％以内になりますが、平均誤差は+ 1.3％のままです。平均誤差がゼロになるように最適化されており、以下を使用できます。

dist = 0.394 * (dx + dy) + 0.554 * max(dx, dy)

-5％から+ 3％のエラーと+ 0.043％の平均エラーが発生します

このアルゴリズムの名前をWebで検索しているときに、次のような8角形近似が見つかりました。

dist = 1007/1024 * max(dx, dy) + 441/1024 * min(dx, dy)

これは本質的に同等であることに注意してください（指数は異なりますが、これらは-1.5％から7.5％の誤差を与えますが、+ /-4％にマッサージすることができます）max(dx, dy) + min(dx, dy) == dx + dy。このフォームを使用すると、minとのmax呼び出しを除外して次のことを行うことができます。

if (dy > dx)
    swap(dx, dy)

dist = 1007/1024 * dx + 441/1024 * dy

これは私のバージョンよりも速くなりますか？誰が知っている...コンパイラと、それがターゲットプラットフォーム用に最適化する方法に依存します。私の推測では、違いを見ることはかなり難しいでしょう。

この問題は、距離計算の実行コストではなく、計算が行われた回数が原因で発生する場合があります。

多くのアクターがいる大規模なゲームの世界では、あるアクターと他のすべてのアクター間の距離をチェックし続けることはスケーラブルではありません。より多くのプレイヤー、NPC、および発射体が世界に入ると、必要な比較の数はで二次的に増加します。O(N^2)

その成長を抑える1つの方法は、適切なデータ構造を使用して、不要なアクターを計算から迅速に破棄することです。

私たちは、効率的に反復すべての俳優への道を探している可能性がある一方で、範囲内とすることが過半数を除いている俳優の範囲外の間違いを。

アクターがワールドスペース全体にかなり均等に分散している場合、バケットのグリッドが適切な構造である必要があります（受け入れられた答えが示唆するように）。アクターへの参照を粗いグリッドで保持することにより、範囲内にある可能性のあるすべてのアクターをカバーするために、近くのバケットのいくつかをチェックするだけで、残りは無視されます。アクターが移動するとき、古いバケツから新しいバケツに移動する必要がある場合があります。

ほぼ均等に分散している俳優たちのために四分木は、 2次元の世界のためのより良い行うことができ、または八分木は、 3次元の世界に適しているであろう。これらは、空のスペースの大きな領域と多くのアクターを含む小さな領域を効率的に分割できる、より汎用的な構造です。以下のために静的な役者がありバイナリ空間分割探索はなく、リアルタイムでの更新もはるかにコストがかかりすぎることは非常に高速です（BSP）、。BSPは、平面を使用して空間を分割し、繰り返し半分にカットし、任意の数の次元に適用できます。

もちろん、アクターをそのような構造に保つには、特にパーティション間を移動しているときにオーバーヘッドがあります。しかし、多くのアクターがいるが関心の範囲が狭い大規模な世界では、コストは、すべてのオブジェクトに対する単純な比較によって発生するコストよりもはるかに低くなければなりません。

スケーラブルなソフトウェア設計には、より多くのデータを受信するにつれてアルゴリズムの費用がどのように増大するかを考慮することが重要です。正しいデータ構造を選択するだけで十分な場合があります。通常、コストはBig O表記を使用して記述されます。

（これは質問に対する直接的な答えではないことは承知していますが、読者によっては役に立つかもしれません。時間を無駄にしてしまった場合はおologiesびします！）

チェビシェフ距離はどうですか？ポイントp、qの場合、次のように定義されます。

したがって、ポイント（2、4）および（8、5）の場合、チェビシェフ距離は6であり、| 2-8 |となります。> | 4-5 |。

さらに、Eをユークリッド距離、Cをチェビシェフ距離とします。次に：

平方根を計算する必要があるため、上限はおそらくあまり使用されませんが、下限は役立つ可能性があります-チェビシェフ距離が範囲外になるのに十分な大きさであれば、ユークリッド距離も必要です計算する必要がなくなります。

トレードオフは、もちろん、チェビシェフ距離が範囲内にある場合、とにかくユークリッド距離を計算する必要があり、時間を浪費することです。純利益になるかどうかを知る唯一の方法です！

非常に単純なローカル最適化は、最初に単一のディメンションをチェックすることです。

あれは ：

distance ( x1, y1 , x1, y2) > fabs (x2 - x1)

したがってfabs (x2 - x1)、最初のフィルターとしてチェックするだけで、かなりのゲインが得られる場合があります。どれくらいが世界のサイズ対関連する範囲に依存します。

さらに、これを空間分割データ構造の代替として使用できます。

すべての関連オブジェクトがx座標の順序でリストにソートされている場合、近くのオブジェクトはリストの近くになければなりません。オブジェクトの移動に伴ってリストが完全に維持されないためにリストの順序が狂った場合でも、既知の速度限界を考慮すると、リストのセクションを減らして近くのオブジェクトを検索できます。

過去に最適化の努力がなされましたsqrt。今日のマシンには適用されなくなりましたが、マジック番号 を使用するQuakeソースコードの例を次に示します0x5f3759df。

float Q_rsqrt( float number )
{
  long i;
  float x2, y;
  const float threehalfs = 1.5F;

  x2 = number * 0.5F;
  y  = number;
  i  = * ( long * ) &y;  // evil floating point bit level hacking
  i  = 0x5f3759df - ( i >> 1 ); // what the hell?
  y  = * ( float * ) &i;
  y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
  // y  = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration (optional)
  // ...
  return y;
}

詳細な説明ここで何が起こっているのは、Wikipediaで見つけることができます。

要するに、これはニュートン法（推定値を反復的に改善する数値アルゴリズム）の数回の反復であり、妥当な初期推定値を提供するためにマジックナンバーが使用されます。

Travisが指摘しているように、この種の最適化は最新のアーキテクチャではもはや有用ではありません。たとえそうであったとしても、ボトルネックを一定の速度で高速化することしかできませんでしたが、アルゴリズムの再設計によってより良い結果が得られる可能性があります。