衝突判定

衝突判定（しょうとつはんてい、Collision Detection）とは、「2つ以上のオブジェクトの交差を検出する」という計算機科学上の問題であり、具体的には「ある物体が別の物体に当たったか（衝突したか）どうか」を判定するプログラム処理のことを指す。ロボット工学、計算物理学、コンピュータゲーム、コンピュータシミュレーション、計算幾何学など、さまざまなコンピューティング分野で応用されている。

衝突判定のアルゴリズムは、2Dオブジェクト同士の衝突判定と3Dオブジェクト同士の衝突判定に分けることができる。

概要

古典的な例だが、衝突判定を科学的に考える上で、ビリヤードの球同士がどのように当たるのかを考えてみるのもよい

ビリヤードの物理シミュレーションをする場合を考えて欲しい。剛体運動と弾性衝突と言う両軸に従って跳ね回るビリヤードの球の物理学は、おそらく読者諸君もよく理解しているだろう。シミュレーションを始める前に、まず、ビリヤード台とボールの非常に正確な物理的記述、そしてすべてのボールの初期位置という、初期状態が提示される。キューボールに「力が加えられる（おそらくはプレーヤーがキュースティックでボールを打ったことが想定される）」という事象が適用された場合、コンピューターのプログラムに従い、すべての球の軌道、正確な動き、および球の最終的な休止場所が算出される。このゲームをシミュレートするプログラムは、いくつかのプログラムのまとまりによって構成されているが、そのうちの1つはビリヤードの球どうしの正確な衝撃を計算する役目を果たす。もちろん、しくじることもある。計算に小さなエラーがあると、ビリヤードボールの最終的な位置が大幅に変化することになる。

ゲームで衝突判定を行う場合もだいたい同じであるが、いくつかの重要な違いがある。一般的なコンピュータシミュレーションでは、現実世界の物理を可能な限り正確にシミュレートする必要があるが、コンピュータゲームにおいては、ハードの性能が許す範囲内で、リアルタイム性を損なわず、なおかつバグが起きないようにシミュレートする必要がある。シミュレーションで得られた結果が、ゲームのプレーヤーが十分満足する範囲内である限り、妥協は許される。

コンピューターシミュレーションによる衝突判定

物質は衝突時の反応方法が当然異なるので。物理シミュレーターでは材質の柔らかさを利用して力を計算するものがある。これにより、現実と同様に次の時間ステップで衝突が解決される。しかし、一部のマテリアルは柔軟性が低いものがあり、これをシミュレーションするとには CPU に非常に高い負荷をかけることとなる。これは演算のレイテンシにつながるため 線形補間やシミュレーションの ロールバック によって衝突時間を推定し、より抽象的な方法 保存則 によって衝突を計算している

calculate the collision by the more abstract

Some iterate the linear interpolation (Newton's method) to calculate the time of collision with a much higher precision than the rest of the simulation. Collision detection utilizes time coherence to allow even finer time steps without much increasing CPU demand, such as in air traffic control.

After an inelastic collision, special states of sliding and resting can occur and, for example, the Open Dynamics Engine uses constraints to simulate them. Constraints avoid inertia and thus instability. Implementation of rest by means of a scene graph avoids drift.

In other words, physical simulators usually function one of two ways, where the collision is detected a posteriori (after the collision occurs) or a priori (before the collision occurs). In addition to the a posteriori and a priori distinction, almost all modern collision detection algorithms are broken into a hierarchy of algorithms. Often the terms "discrete" and "continuous" are used rather than a posteriori and a priori.

A posteriori (discrete) versus a priori (continuous)

In the a posteriori case, we advance the physical simulation by a small time step, then check if any objects are intersecting, or are somehow so close to each other that we deem them to be intersecting. At each simulation step, a list of all intersecting bodies is created, and the positions and trajectories of these objects are somehow "fixed" to account for the collision. We say that this method is a posteriori because we typically miss the actual instant of collision, and only catch the collision after it has actually happened.

In the a priori methods, we write a collision detection algorithm which will be able to predict very precisely the trajectories of the physical bodies. The instants of collision are calculated with high precision, and the physical bodies never actually interpenetrate. We call this a priori because we calculate the instants of collision before we update the configuration of the physical bodies.

The main benefits of the a posteriori methods are as follows. In this case, the collision detection algorithm need not be aware of the myriad of physical variables; a simple list of physical bodies is fed to the algorithm, and the program returns a list of intersecting bodies. The collision detection algorithm doesn't need to understand friction, elastic collisions, or worse, nonelastic collisions and deformable bodies. In addition, the a posteriori algorithms are in effect one dimension simpler than the a priori algorithms. Indeed, an a priori algorithm must deal with the time variable, which is absent from the a posteriori problem.

On the other hand, a posteriori algorithms cause problems in the "fixing" step, where intersections (which aren't physically correct) need to be corrected. Moreover, if the discrete step is too large, the collision could go undetected, resulting in an object which passes through another if it is sufficiently fast or small.

The benefits of the a priori algorithms are increased fidelity and stability. It is difficult (but not completely impossible) to separate the physical simulation from the collision detection algorithm. However, in all but the simplest cases, the problem of determining ahead of time when two bodies will collide (given some initial data) has no closed form solution—a numerical root finder is usually involved.

Some objects are in resting contact, that is, in collision, but neither bouncing off, nor interpenetrating, such as a vase resting on a table. In all cases, resting contact requires special treatment: If two objects collide (a posteriori) or slide (a priori) and their relative motion is below a threshold, friction becomes stiction and both objects are arranged in the same branch of the scene graph.

Optimization

The obvious approaches to collision detection for multiple objects are very slow. Checking every object against every other object will, of course, work, but is too inefficient to be used when the number of objects is at all large. Checking objects with complex geometry against each other in the obvious way, by checking each face against each other face, is itself quite slow. Thus, considerable research has been applied to speed up the problem.

Exploiting temporal coherence

In many applications, the configuration of physical bodies from one time step to the next changes very little. Many of the objects may not move at all. Algorithms have been designed so that the calculations done in a preceding time step can be reused in the current time step, resulting in faster completion of the calculation.

At the coarse level of collision detection, the objective is to find pairs of objects which might potentially intersect. Those pairs will require further analysis. An early high performance algorithm for this was developed by Ming C. Lin at the University of California, Berkeley [1], who suggested using axis-aligned bounding boxes for all n bodies in the scene.

Each box is represented by the product of three intervals (i.e., a box would be $I_{1}\times I_{2}\times I_{3}=[a_{1},b_{1}]\times [a_{2},b_{2}]\times [a_{3},b_{3}]$). A common algorithm for collision detection of bounding boxes is sweep and prune. We observe that two such boxes, $I_{1}\times I_{2}\times I_{3}$ and $J_{1}\times J_{2}\times J_{3}$ intersect if, and only if, $I_{1}$ intersects $J_{1}$, $I_{2}$ intersects $J_{2}$ and $I_{3}$ intersects $J_{3}$. We suppose that, from one time step to the next, $I_{k}$ and $J_{k}$ intersect, then it is very likely that at the next time step, they will still intersect. Likewise, if they did not intersect in the previous time step, then they are very likely to continue not to.

So we reduce the problem to that of tracking, from frame to frame, which intervals do intersect. We have three lists of intervals (one for each axis) and all lists are the same length (since each list has length $n$, the number of bounding boxes.) In each list, each interval is allowed to intersect all other intervals in the list. So for each list, we will have an $n\times n$ matrix $M=(m_{ij})$ of zeroes and ones: $m_{ij}$ is 1 if intervals $i$ and $j$ intersect, and 0 if they do not intersect.

By our assumption, the matrix $M$ associated to a list of intervals will remain essentially unchanged from one time step to the next. To exploit this, the list of intervals is actually maintained as a list of labeled endpoints. Each element of the list has the coordinate of an endpoint of an interval, as well as a unique integer identifying that interval. Then, we sort the list by coordinates, and update the matrix $M$ as we go. It's not so hard to believe that this algorithm will work relatively quickly if indeed the configuration of bounding boxes does not change significantly from one time step to the next.

In the case of deformable bodies such as cloth simulation, it may not be possible to use a more specific pairwise pruning algorithm as discussed below, and an n-body pruning algorithm is the best that can be done.

If an upper bound can be placed on the velocity of the physical bodies in a scene, then pairs of objects can be pruned based on their initial distance and the size of the time step.

Pairwise pruning

Once we've selected a pair of physical bodies for further investigation, we need to check for collisions more carefully. However, in many applications, individual objects (if they are not too deformable) are described by a set of smaller primitives, mainly triangles. So now, we have two sets of triangles, $S={S_{1},S_{2},\dots ,S_{n}}$ and $T={T_{1},T_{2},\dots ,T_{n}}$ (for simplicity, we will assume that each set has the same number of triangles.)

The obvious thing to do is to check all triangles $S_{j}$ against all triangles $T_{k}$ for collisions, but this involves $n^{2}$ comparisons, which is highly inefficient. If possible, it is desirable to use a pruning algorithm to reduce the number of pairs of triangles we need to check.

The most widely used family of algorithms is known as the hierarchical bounding volumes method. As a preprocessing step, for each object (in our example, $S$ and $T$) we will calculate a hierarchy of bounding volumes. Then, at each time step, when we need to check for collisions between $S$ and $T$, the hierarchical bounding volumes are used to reduce the number of pairs of triangles under consideration. For simplicity, we will give an example using bounding spheres, although it has been noted that spheres are undesirable in many cases.

If $E$ is a set of triangles, we can precalculate a bounding sphere $B(E)$. There are many ways of choosing $B(E)$, we only assume that $B(E)$ is a sphere that completely contains $E$ and is as small as possible.

Ahead of time, we can compute $B(S)$ and $B(T)$. Clearly, if these two spheres do not intersect (and that is very easy to test), then neither do $S$ and $T$. This is not much better than an n-body pruning algorithm, however.

If $E={E_{1},E_{2},\dots ,E_{m}}$ is a set of triangles, then we can split it into two halves $L(E):={E_{1},E_{2},\dots ,E_{m/2}}$ and $R(E):={E_{m/2+1},\dots ,E_{m-1},E_{m}}$. We can do this to $S$ and $T$, and we can calculate (ahead of time) the bounding spheres $B(L(S)),B(R(S))$ and $B(L(T)),B(R(T))$. The hope here is that these bounding spheres are much smaller than $B(S)$ and $B(T)$. And, if, for instance, $B(S)$ and $B(L(T))$ do not intersect, then there is no sense in checking any triangle in $S$ against any triangle in $L(T)$.

As a precomputation, we can take each physical body (represented by a set of triangles) and recursively decompose it into a binary tree, where each node $N$ represents a set of triangles, and its two children represent $L(N)$ and $R(N)$. At each node in the tree, we can precompute the bounding sphere $B(N)$.

When the time comes for testing a pair of objects for collision, their bounding sphere tree can be used to eliminate many pairs of triangles.

Many variants of the algorithms are obtained by choosing something other than a sphere for $B(T)$. If one chooses axis-aligned bounding boxes, one gets AABBTrees. Oriented bounding box trees are called OBBTrees. Some trees are easier to update if the underlying object changes. Some trees can accommodate higher order primitives such as splines instead of simple triangles.

Exact pairwise collision detection

Once we're done pruning, we are left with a number of candidate pairs to check for exact collision detection.

A basic observation is that for any two convex objects which are disjoint, one can find a plane in space so that one object lies completely on one side of that plane, and the other object lies on the opposite side of that plane. This allows the development of very fast collision detection algorithms for convex objects.

Early work in this area involved "separating plane" methods. Two triangles collide essentially only when they can not be separated by a plane going through three vertices. That is, if the triangles are ${v_{1},v_{2},v_{3}}$ and ${v_{4},v_{5},v_{6}}$ where each $v_{j}$ is a vector in $\mathbb {R} ^{3}$, then we can take three vertices, $v_{i},v_{j},v_{k}$, find a plane going through all three vertices, and check to see if this is a separating plane. If any such plane is a separating plane, then the triangles are deemed to be disjoint. On the other hand, if none of these planes are separating planes, then the triangles are deemed to intersect. There are twenty such planes.

If the triangles are coplanar, this test is not entirely successful. One can add some extra planes, for instance, planes that are normal to triangle edges, to fix the problem entirely. In other cases, objects that meet at a flat face must necessarily also meet at an angle elsewhere, hence the overall collision detection will be able to find the collision.

Better methods have since been developed. Very fast algorithms are available for finding the closest points on the surface of two convex polyhedral objects. Early work by Ming C. Lin used a variation on the simplex algorithm from linear programming. The Gilbert-Johnson-Keerthi distance algorithm has superseded that approach. These algorithms approach constant time when applied repeatedly to pairs of stationary or slow-moving objects, when used with starting points from the previous collision check.

The end result of all this algorithmic work is that collision detection can be done efficiently for thousands of moving objects in real time on typical personal computers and game consoles.

A priori pruning

Where most of the objects involved are fixed, as is typical of video games, a priori methods using precomputation can be used to speed up execution.

Pruning is also desirable here, both n-body pruning and pairwise pruning, but the algorithms must take time and the types of motions used in the underlying physical system into consideration.

When it comes to the exact pairwise collision detection, this is highly trajectory dependent, and one almost has to use a numerical root-finding algorithm to compute the instant of impact.

As an example, consider two triangles moving in time ${v_{1}(t),v_{2}(t),v_{3}(t)}$ and ${v_{4}(t),v_{5}(t),v_{6}(t)}$. At any point in time, the two triangles can be checked for intersection using the twenty planes previously mentioned. However, we can do better, since these twenty planes can all be tracked in time. If $P(u,v,w)$ is the plane going through points $u,v,w$ in $\mathbb {R} ^{3}$ then there are twenty planes $P(v_{i}(t),v_{j}(t),v_{k}(t))$ to track. Each plane needs to be tracked against three vertices, this gives sixty values to track. Using a root finder on these sixty functions produces the exact collision times for the two given triangles and the two given trajectory. We note here that if the trajectories of the vertices are assumed to be linear polynomials in $t$ then the final sixty functions are in fact cubic polynomials, and in this exceptional case, it is possible to locate the exact collision time using the formula for the roots of the cubic. Some numerical analysts suggest that using the formula for the roots of the cubic is not as numerically stable as using a root finder for polynomials.

Spatial partitioning

Alternative algorithms are grouped under the spatial partitioning umbrella, which includes octrees, binary space partitioning (or BSP trees) and other, similar approaches. If one splits space into a number of simple cells, and if two objects can be shown not to be in the same cell, then they need not be checked for intersection. Since BSP trees can be precomputed, that approach is well suited to handling walls and fixed obstacles in games. These algorithms are generally older than the algorithms described above.

Bounding boxes

Bounding boxes (or bounding volumes) are most often a 2D rectangle or 3D cuboid, but other shapes are possible. A bounding box in a video game is sometimes called a Hitbox. The bounding diamond, the minimum bounding parallelogram, the convex hull, the bounding circle or bounding ball, and the bounding ellipse have all been tried, but bounding boxes remain the most popular due to their simplicity. Bounding boxes are typically used in the early (pruning) stage of collision detection, so that only objects with overlapping bounding boxes need be compared in detail.

Triangle centroid segments

A triangle mesh object is commonly used in 3D body modeling. Normally the collision function is a triangle to triangle intercept or a bounding shape associated with the mesh. A triangle centroid is a center of mass location such that it would balance on a pencil tip. The simulation need only add a centroid dimension to the physics parameters. Given centroid points in both object and _target it is possible to define the line segment connecting these two points.

The position vector of the centroid of a triangle is the average of the position vectors of its vertices. So if its vertices have Cartesian coordinates $(x_{1},y_{1},z_{1})$, $(x_{2},y_{2},z_{2})$ and $(x_{3},y_{3},z_{3})$ then the centroid is $\left({\frac {(x_{1}+x_{2}+x_{3})}{3}},{\frac {(y_{1}+y_{2}+y_{3})}{3}},{\frac {(z_{1}+z_{2}+z_{3})}{3}}\right)$.

Here is the function for a line segment distance between two 3D points. $\mathrm {distance} ={\sqrt {(z_{2}-z_{1})^{2}+(x_{2}-x_{1})^{2}+(y_{2}-y_{1})^{2}}}$

Here the length/distance of the segment is an adjustable "hit" criteria size of segment. As the objects approach the length decreases to the threshold value. A triangle sphere becomes the effective geometry test. A sphere centered at the centroid can be sized to encompass all the triangle's vertices.

ゲームの衝突判定

ビデオゲームにおいては、非常に限られた計算機時間をいくつかのタスクに分割する必要がある。ゲームではこのようなリソースの制限に加え、かなり原始的な衝突検出アルゴリズムを使用せざるをえないという制限があったにもかかわらず、ゲームのプログラマーは、一応はプレイヤーの信頼に足るプログラムを作り上げて来た。

2Dのゲームの時代においては、処理するオブジェクトの数が非常に限られていたため、すべてのオブジェクトの衝突判定を行うことはそれほど問題ではなかった。2Dのゲームでは、ハードウェアにピクセル単位の衝突判定が実装されている場合もあり、その場合はハードウェアが画面上のスプライト同士の間で重複するピクセルを検出して報告してくれるので、ソフトの開発者としても効率的で楽だった。もしハードの支援が無かった場合でも、画面にタイルパターンを並べ、BGのタイルパターンと自機のスプライトが重なったかどうかをチェックするだけで十分な衝突判定が可能であった。ペアワイズ法を使った衝突判定のチェックにおいては、「ヒットボックス」と呼ばれる長方形の境界（円形の場合もある）が使用され、これで十分に正確な衝突判定が行えると考えられて来た。

3Dのゲームにおける衝突判定は、「空間をいくつかの区画に分割して刈り込む」という空間分割法か、もしくは「3Dのオブジェクトをいくつかの球に分割してペアワイズチェックを行う」という方法を長い間使用していた。現実を厳密にシミュレートしようとするようなタイプのシミュレーションゲームはともかくとして、ゲームで物理的に正確な衝突判定を行うことはまれである。そもそも、たとえゲームで正確な衝突判定を目指したところで、必ずしもすべての場合において正確な衝突判定のチェックが行えるわけでもない。

ゲームは実際の物理を模倣する必要がないため、衝突判定の確実性はそれほど問題ではない。ほとんどすべてのゲームは事後衝突検出を使用しており、もし衝突が検知された場合は非常に単純なルールを使用して解決される。たとえば、キャラクターが壁にめり込んだことが検知された場合、キャラクターは単に壁にめり込んでいなかった最後の場所まで戻される、と言う処理を行うゲームもある。一部のゲームでは、キャラクターが壁にめり込むまでに移動できる距離を計算し、壁にめり込まない距離までしか移動できないようにする、という処理を行う。

ゲームでフィールドとの衝突判定を行う場合、基本的にはキャラクターを「点」で近似するだけで十分である。この場合、バイナリ空間分割木は、「点」がフィールド内にめり込んだ状態であるか、それともそうでないかをチェックするための実行可能で効率的でシンプルなアルゴリズムを提供する。キャラクター同士の衝突、もしくは敵弾や当たるとダメージを受ける物との衝突判定はまた別の手法を用いて行われる。

シミュレーションの堅実性は、あらゆる入力に合理的な方法で反応するかどうかで決まる。たとえば超高速なレーシングゲームを想像すると、1つのシミュレーションステップから次のシミュレーションステップへと移行するごとに（つまり、1フレームごとに）、車はレーシングトラックに沿ってかなりの距離を進むことが想定される。もしトラックに薄い障害物（レンガの壁など）があった場合、フレームごとの移動距離が大きすぎて衝突判定が間に合わず、車が壁をすり抜けるバグが起こりがちだが、現実世界では車が壁をすり抜ける可能性はまったくない。シミュレーションと言う観点からすると、これは非常に望ましくないバグである。他の例を挙げると、事後衝突判定アルゴリズムが必要とする「軌道修正（フィックス）」が正しく実装されていないため、キャラクターがフィールドに復帰できず、壁の中にキャラクターが閉じ込められたり、キャラクターが壁を通過したりして、下に床が無い場合は無限に落下し続ける致命的なバグが発生することがある。「無限落下」やスーパーマリオ64の「ケツワープ」などと呼ばれるバグが知られている。これらのバグは、衝突判定および物理シミュレーションシステムの欠陥によるものである。『Big Rigs：Over the Road Racing』は、衝突判定システムにバグがある、もしくは衝突判定システムが欠如していることにより、「史上最低のクソゲー」として名高い。

ヒットボックス

ヒットボックス（hitbox）とは、ビデオゲームにおいてリアルタイムの衝突判定のために一般的に使用される「見えない四角」であり、バウンディングボックスの一種である。3Dモデル（3Dゲームの場合）やスプライト（2Dゲームの場合）などの可視オブジェクトと同じ場所にアタッチされることが多く、2Dゲームでは長方形、3Dゲームでは直方体の形をしている。円形または球形をしている場合もよくあるが、それでもほとんどの場合は「ボックス」と呼ばれる（海外でも）。可動オブジェクトでは、モーション中の精度を確保するために、可動する各パーツにヒットボックスがアタッチされているのが一般的である。

ヒットボックスは、キャラクターと敵の打撃や弾丸との衝突判定を取る場合など、「一方向」の衝突を検出するために使用される。衝突によってフィードバックが発生する場合、例えば壁にぶつかった際にフィードバックによって反発が起き、すぐ次のフレームでは壁から引き離される、と言うような場合は、ヒットボックスの位置が絶えず変化することになり、ヒットボックスの位置の管理がとても面倒になるので、ヒットボックス方式を使うのは適していない。このような場合はヒットボックス方式より単純な実装である「軸並行境界ボックス方式（Axis-Aligned Bounding Box、AABB方式）」を使うのが適している。しかしプレーヤー目線では、これらの実装方式を区別せず、どちらも単に「ヒットボックス」と言う場合も多い。

ヒットボックスとよく似た概念としてハートボックス（hurtbox）と言うものも存在する。「ダメージを受ける衝突判定」と「ダメージを与える衝突判定」を使い分ける必要がある場合、前者を「ヒットボックス（あたり判定）」と呼び、後者を「ハートボックス（攻撃判定）」と呼ぶ。たとえば、攻め側のパンチのヒットボックスが相手側のハートボックスと衝突した場合は攻撃が「通った」と判定されるが、相手側のヒットボックスと衝突した場合は「相打ち」または「打撃キャンセル」と判定されたい、というような場合に使われる。ハートボックス同士が衝突しても何も起きない。なお、この用語は業界全体で標準化されておらず、「ヒットボックス」と「ハートボックス」の定義がこれと逆になっているゲームもあり、またどちらも単に「ヒットボックス」と呼ぶゲームもある。

ゲームの衝突判定の手法

ゲームにおいては衝突判定の精密性よりもリアルタイム性が重視されるので、以下のような手法がよく用いられる。

ヒットボックス方式

衝突判定を取りたい双方のオブジェクトを「四角い箱（矩形、ボックス）」で梱包することを考える。この「四角い箱」のことを一般的に「境界ボックス（バウンディングボックス）」と呼ぶが、ゲーム業界では「ヒットボックス」と呼ぶ。以下に述べるのは、ヒットボックス方式を用いた衝突判定の「基本的な方法」である。

2D空間において、それぞれの矩形を座標(x, y) と幅・高さ(lx, ly) で表す。ふたつの矩形A・矩形B について衝突判定を行うには、以下の条件が成り立っているかどうかを調べる。成り立てば当たり、そうでなければ外れと判定できる。

$(A_{x}\leq B_{x}+B_{lx})\land (B_{x}\leq A_{x}+A_{lx})\land (A_{y}\leq B_{y}+B_{ly})\land (B_{y}\leq A_{y}+A_{ly})$

3D空間においては、衝突判定を取りたい双方のオブジェクトを「直方体」とみなし、幅・高さ・奥行き(lx, ly, lz) で表す以外は上と同じである。

ヒットボックス方式の主な実装方法は、上で述べた他に、境界球方式、AABB方式、OBB方式、凸包方式、などがある。後者に行くにしたがって精密な衝突判定が行えるが、計算コストが大きくなり、特に凸包方式はゲームではまず使われない。2010年代以降には凸包同士の衝突計算をGJKアルゴリズムを用いてGPUでリアルタイムで実行するための研究が進んでおり、今後のゲームエンジンに実装される可能性もある（すでに実装されている可能性もある）が、複雑なオブジェクト同士の衝突判定を行う伝統的な方法としては、複数のヒットボックスを組み合わせて近似する方式が使われる。

境界円・境界球

ヒットボックス方式の一種で、衝突判定を取りたい双方のオブジェクトを「円形」または「球形」とみなす。円形の境界ボックスの事を「ヒットボックス」と呼ぶ。ちなみに海外でも円形なのに「ヒットボックス」と呼ばれる。「境界円」「ヒットサークル」と呼ばれることもまれにある。

円を中心(x,y)、半径 r で表すと、二つの円 A, B が当たっていることは「Aの中心とBの中心の距離が、Aの半径とBの半径の和以下である」ことと同値であるから、円どうしの衝突判定は

$(A_{x}-B_{x})^{2}+(A_{y}-B_{y})^{2}\leq (A_{r}+B_{r})^{2}$

これを3次元に拡張すると、球と球の衝突判定を行うことができる。球形の境界ボックスのことを「境界球(Bounding Sphere)」と呼ぶが、やはりこれも「ヒットボックス」と呼ぶことが多い。

$(A_{x}-B_{x})^{2}+(A_{y}-B_{y})^{2}+(A_{z}-B_{z})^{2}\leq (A_{r}+B_{r})^{2}$

軸並行境界ボックス方式（AABB方式）

特に3D空間で衝突判定を取る場合において、上記の方式では管理が面倒になる場合は「軸並行境界ボックス方式(Axis Aligned Bounding Box, AABB方式)」を使う。

ヒットボックス方式の「基本的な方法」ではオブジェクトのバウンディングボックス（境界ボックス）の左上の点をオブジェクト自体の座標とみなし、そこから右下までの長さを取るのが一般的なのに対して、AABB方式ではヒットボックスの中心座標をオブジェクト自体の座標とみなし、そこからxyz軸方向に±何mの広がりがある、という表し方をする。ヒットボックスの中心を(x,y,z), 双方向への広がりの大きさを(rx,ry,rz)とすると、このヒットボックスは x方向については x-rx ～ x+rx, y方向には y-ry ～ y+ry, z方向には z-rz ～ z+rz の範囲を占める。軸並行境界ボックス方式を用いてふたつのヒットボックスA・Bについて衝突判定を行うには、以下のようになる。

$(A_{x}-A_{rx}\leq B_{x}+B_{rx})\land (B_{x}-B_{rx}\leq A_{x}+A_{rx})$ $\land (A_{y}-A_{ry}\leq B_{y}+B_{ry})\land (B_{y}-B_{ry}\leq A_{y}+A_{ry})$ $\land (A_{z}-A_{rz}\leq B_{z}+B_{rz})\land (B_{z}-B_{rz}\leq A_{z}+A_{rz})$

AABBは大雑把な衝突判定や可視判定で使われることがある。

AABB方式は2Dの衝突判定を取る場合でも使われることがある。特に四角いヒットボックスと円形のヒットボックスの衝突判定を取る時は、四角いヒットボックスの座標をAABB方式で管理した方が楽である。

有向境界ボックス（OBB方式）

有向境界ボックス（Oriented Bounding Box）。

ピクセルパーフェクト方式（pixel perfect collision detectionまたはper-pixel collision detection, PPCD）

2Dゲームにおいて、ピクセル単位で衝突判定を取る方式。スプライト画像をベースとする衝突判定の方式なのでimage-based collision detectionともいう。1980年代頃までの8bit機ではスプライトの表示位置ごとの衝突判定を取ることしかできなかったが（当時のスプライトの大きさは基本的に8x8であったため、8ドット単位の衝突判定になった）、この方式を用いることで、1ドット単位の衝突判定が可能になる。

MSX2（1985年発売）の「スプライトモード2」ではハードウェアの支援が得られることがウリの一つであった。ハードウェアの支援が得られないハードにおいてソフトウェアベースでピクセルパーフェクトを実現する方式がいくつかあるが、現代においてこれをソフトウェアで実装するには、基本的には複数のヒットボックスを組み合わせて衝突判定を取る方式が用いられる。そもそも現代の2Dゲームエンジンでは8bit機時代のようなスプライト機能をソフトウェア上で擬似的に実装しているだけであるので、現代のハードウェアの性能をもってすれば、ソフトウェアベースでピクセルパーフェクトを実装することは特に困難ではない。

バーチャファイター方式

複雑な形状のポリゴンモデルの衝突判定を行うとき、ポリゴンモデルを「複数の球の組み合わせ」とみなし、それぞれの球において衝突判定を行うことでオブジェクト同士の衝突判定を行うことができる。セガの初代『バーチャファイター』（1993年）で初めて実装された手法。現在はポリゴンのキャラクター同士の衝突判定を取る際の基本的な手法であるが、これが初めて実装された1993年当時は衝撃的であったとのこと（『バーチャファイター』以前のゲームは、各キャラクターの姿勢や動作の一つ一つについてヒットボックスを個別に実装していたため、メモリを食う上にキャラクターの見た目と衝突判定が一致していなかった）。

バイナリ空間分割木方式（BSP木方式）

バイナリ空間分割木（Binary space partitioning, BSP木）を用いる方法。広大な3D空間において衝突判定を行いたい場合、空間をいくつかの区画に分割して刈り込む、と言う方法を取る。

球体スウィープボリューム（SSV）

上記の衝突判定ではすべて、オブジェクト同士が衝突しているかどうかを「1フレームごと」にチェックする、つまり「離散的（Discrete）」な衝突検出法を用いた。1フレームごとにしか衝突判定を行わないことで、高速な衝突判定が行えるが、しかしこの方式を用いた場合、オブジェクトが速すぎてヒットボックスが1フレーム以下の時間で壁を通り過ぎてしまって衝突判定が行われない、トンネリング（いわゆる「壁抜け」）が起こりがちである。それを防ぐためには、1フレームごとに離散的に衝突判定を行うのではなく、連続的に衝突判定を行う「連続的衝突判定」（Continuous Collision Detection, CCD）と言う手法を取るのが一般的である。そのための最も一般的な手法がこれである。

オブジェクトを球体で近似する。この球が、現在の速度で直線的に動くと考え、「ある点」から「ある点」まで移動することで出来る軌跡を考える。この結果できた、カプセルのような形をしたボリューム（掃引体）のことを「球体スウィープボリューム（sphere-swept volume:SSV）」と言う。このボリュームが別のオブジェクトと接触していた場合、衝突が発生していると考えられる。

球体スウィープボリューム同士の衝突判定を行うことで、高速に動くオブジェクト同士の衝突判定も行える。動く球同士の衝突判定の取り方を説明すると、動く球は、移動開始時の中心・速度ベクトルV・半径、で表すことができる。現在のフレーム(フレーム0）と次のフレーム（フレーム1）の間の時間において、0 < t < 1 となる媒介変数 t を使うと、球Aの中心は (A0 + t Va), 球Bの中心は (B0 + t Vb) と表せる。このように動いていく球A・球Bの中心どうしの距離が、半径の和以下になるような時刻 t が存在するか? を求める。

この手法では物体の角運動を無視しているため、回転運動をしているオブジェクトではやはり「壁抜け」を起こしやすい欠点があるのと、かなり計算機負荷の高い手法であるため、大量のオブジェクトが存在する状況では計算量が増大し、オーバーヘッド（いわゆる「処理落ち」）が発生する懸念がある。

2Dの場合は、円形のスウィープボリュームを用いる以外は同じである。1990年代以降のFPSでよく使われている（例えばアンリアルエンジンでは「カプセルスイープ」として実装されている）が、敵が遠くにいてもショットガンが1フレームで高速に真っ直ぐに敵に着弾するという、文字通りアンリアルな挙動になりがちである。

投機的連続的衝突判定（投機的CCD）

球体スウィープボリュームを用いて連続的衝突判定（CCD）を行う「スイープに基づくCCD」では物体が等速直線運動を行うものとして、物体の角運動を無視しているため、やはり「壁抜け」を起こしやすい欠点がある。特にフリッパーが直線運動を全く行わない（回転運動しか行わない）ピンボールゲームでは顕著で、高速に動くボールが回転するフリッパーをすり抜ける致命的な結果となる。これを防ぐために、Unityでは投機的連続的衝突判定（投機的CCD）法が採用されている。詳しくはUnityユーザーマニュアルを参照のこと。

その他

• 球と直方体であたり判定を取る場合、双方を球か直方体で近似すると計算が簡単になるが、見た目と衝突判定が食い違うのでプレイヤーが不満を抱く。一方でポリゴン同士の衝突判定とみなして衝突判定を行うと計算量が膨大になる。これらを緩和するため、直方体を楕円形で近似して衝突判定を行う方法がある（コナミの3DO M2用ゲーム『とべ!ポリスターズ』開発チームのちちびんたつかさが開発した手法）。

• ヒットボックスを「点」で近似する手法がある。衝突判定のプログラムが格段に簡単になる上、自機の当たり判定が極小（1ドット）になってプレーヤーも満足する。

• 複雑なポリゴンモデルの衝突判定を取る場合、複数のポリゴンを一つのポリゴンとみなして衝突判定を行ったり、一旦ボクセルに変換して衝突判定を行う手法がある。また、投影像の画素ごとの奥行き値を比較して衝突判定を行うという手法もある。これらは3DOを擁する松下電器産業の開発した技術。

• 「壁抜け」を防ぐために、単に「フレームレートを限界まで上げる」という手法がある。ハードウェアを自作するならともかく、既定のスペックがあるゲーム機などでは厳しい。

関連項目

• ヒットテスト
• バウンディングボリューム
• ゲーム物理
• GJKアルゴリズム
• 物理演算エンジン
• ラグドール物理
• バイナリ空間分割

外部リンク

• University of North Carolina at Chapel Hill collision detection research web site
• Prof. Steven Cameron (Oxford University) web site on collision detection
• How to Avoid a Collision by George Beck, Wolfram Demonstrations Project.
• Bounding boxes and their usage
• Separating Axis Theorem
• Unity 3d Collison
• Godot Physics Collison