非常にシンプルな3Dレーシングゲームでは、衝突はどのように処理されますか？

いくつかのシンプルな3Dカーレーシングゲーム（特にOutrun 2 / Motoracerなどのゲーム）で衝突がどのように行われるのか疑問に思いました。

複雑な環境（オープンワールド）のクラシックカーレーシングゲームでは、これは基本的なボックス（車用）から飛行機の衝突（トラック、建物など）で行われると思います。全体は、いくつかのバウンディングボックスを使用して最適化されます（これは、多くのゲームで衝突が行われる方法です）。

Outrun 2 / Motoracerのようなゲームでは、ゲームプレイは非常にシンプルなので、開発者はそれを必要としない可能性があり、すべてが大幅に簡略化されている可能性があります。それをプレイしたことがない人のために、これはとても具体的です：

• 車/バイクは常に道路に接着されています。
• 道路は常に同じサイズで、非常にシンプルな形状です。
• 唯一の可能性は、その道路をたどること、道路を離れること、または他の物と衝突することは不可能です（他の車/バイクを除いて、私たちは気にしません）。
• あなたが道路に衝突すると、非常に基本的なアーケードの衝突が行われます（車は単にそこから押し出されます）

これが衝突が起こったと思う方法です：

トラック全体は、巨大な3Dベジェ曲線と見なすことができます。そのカーブから、道路のポリゴンを生成できます（カーブから生成された前面、左、上方向のベクトルを使用）。他の要素（家、木など）も、この方法を使用して配置および整列できます。

次に、衝突を処理する（そして車を引く）には：

1）現在の車の3D位置から3Dカーブ上の最も近い位置を見つけます。つまり、3D車の位置をベジェカーブの位置に変換します。道路上のすべての3D位置は、3Dカーブに沿った変位（t）+横変位（d）と見なすことができます。はっきりしない場合は、下の画像を確認してください（これは2Dの例ですが、3Dにも簡単に当てはまります）。

t = 0の場合、トラックセクションの先頭にあり、t = 1の場合、末尾にあります。d = -1または1台の車がトラックの境界にある場合、d = 0台の車が道路の真ん中にある場合

2）を用いて道路に車を位置合わせtし、d（非常に簡単：いずれかのt及びd値iは3D位置+アップ/正面/左ベクトルを得ることができます）。車は今道路に接着されています

3）d車の横変位を確認します。値が大きすぎる場合(d > 1)や低すぎる場合は、(d < -1)車が軌道から外れています。クリップして、車を正しい場所に置いてください。

これにより、3Dカリングも非常に簡単になり、現在の車のt位置からまでトラックを描くだけt + some_big_enough_value_to_avoid_visible_clippingです。

あるいは、私が完全に間違っているかもしれません。車の衝突（境界ボックス）と、トラックを表す非常に簡略化されたポリゴンのセット（建物などなし）をチェックするだけの方が、はるかに速く簡単でした。3Dワールド（および結果のコリジョンモデル）は、いくつかのサードパーティツール（ゲームの実行時に3Dカーブはなく、一連のポリゴンのみ）を使用して、以前に単純に生成されていました。

私はあなたが説明するものに似たいくつかの商用ゲームに取り組みました。

これらの各ゲームでは、実際にはポリゴンがトラックの側面に沿って目に見えない「壁」を作成し、それらの壁に対して従来の衝突テストを行いました。これは、目に見えない壁の内側の道路の側面に追加の衝突可能な危険がある可能性があることを意味し、また、スプラインアプローチで通常よりも速く道路の幅を変化させることができます。

しかし、そうは言っても、衝突のトンネリング/グリッチから保護するために、衝突がどのように機能するかをセクションに記載しましたが、このシステムはAIロジックのレースにも頻繁に使用されました。HUDに「1st / 2nd / 3rd / etc」インジケーターを表示できるように、先頭の車を決定するためにも使用しました。時々、このデータは、大クラッシュの後の車の復活にも使用されました。

衝突がどのように機能するかを見逃した1つのピースは、このようなスプラインで作業しているとき、通常はスプラインにリブを与えることです。。リブは、トラックがスプラインから各方向の横にどれだけ伸びるかを表すデータのビットです。したがって、100メートルの長さのスプラインの場合、50のリブがあり、その長さに沿って2メートルごとにトラック幅が与えられます。これにより、トラックはその範囲に沿って幅を変更できます。私が取り組んだゲームでは、これらのリブは「トラック表面」と「運転可能領域」も区別しています。つまり、スプラインの中央からどれくらいの距離にあるかを表す道路の幅のセットと、砂/草/それ以外の距離の幅を示す別の幅があります。これにより、プレイヤーはトラックから妥当な距離を走行しながら、実際の路面がどこにあるかをAIに認識させることができます。

私が取り組んだ多くのゲームは、他のデータも肋骨に保存しています。1つのゲームは、リブにトラックの照明情報を焼き付けて、領域が影にあるかどうかを簡単に計算します（その後、自動車のレンダリング、レンズフレアを描画するかどうかの決定、およびその他の効果に使用されました）。もう1つは、どのシネマティックカメラ配置がスプラインのその部分を見ることができるかについての情報で焼き付けられていたので、再生中に視線計算を行う必要がありませんでした。さらにもう1つは、スプライン上にある車線の数、その方向、および各車線が配置された水平方向の変位に関する情報を含みました。これにより、車線内を正しく走行できる交通車両を含めることができました。リブは、路面について必要になる可能性のあるあらゆる種類のデータを保存するのに最適です。

リブは通常、スプラインに関連付けられている配列に格納されます。速度上の理由から、通常の実装ではリブが等間隔に配置されるため、スプラインに沿ったオブジェクトの距離がわかったら、スプラインに沿った距離をリブ間の距離で割ることにより、配列内の最も近いリブインデックスを計算できます。そうしないと、rib配列をバイナリ検索して正しい道路幅データを見つけるのに行き詰まります。

カリングの説明は、スプラインアプローチの使用方法についての基本的な説明を提供しますが、実際には提案よりも少し複雑です-この方法でスプラインを使用してカリングを行うと、長いヘアピンターンで反対側が描画されないことがよくありますトラックに沿った距離で測定すると、カラスが飛ぶときに測定すると数メートルしか離れていない場合でも、曲がりの反対側が非常に遠く離れている可能性があるため。さらに、ワールドジオメトリが表示される距離は、通常、トラックメッシュが表示される距離とは異なるため、これらもこのシステムには適合しません。私の経験では、ほとんどの場合、モデルを描画する必要があるかどうかを決定するためにトラック追跡ロジックに依存しない方がよいということです。これははるかに信頼性が高く、標準のカメラ錐台テストを使用するためのグリッチが少なくなります。

私のOpenGLレーサーでは、最初は2つの円を使用してトラックの境界を定義することから始めましたが、面倒すぎるように思えました。glReadPixelを使用してピクセルカラーを読み取るだけです。プレイヤーの車が緑（草色）のピクセルの上にある場合、動きはさらに制限されます。パフォーマンスへの影響はほとんどありません。