前のページがあります

Cones

すぐにダメージに取り組むのではなく、最初はトラック上のコーンを動くようにすることから始めました。これによって何を改善すべきなのかがよく分かりました。

既存の技術を使って動くコーンの実装に成功し、表面上は良いステップを踏み出したように見えましたが、コーンが動くほどにシステムに改善が必要であることが明らかになってきました。

マシンとコーンのコリジョン(衝突)モデルは、一連のスフィア(球状体)を使って判定・再現します。これは、シンプルでトラックジオメトリに対して多くのスフィアを効率的にテストできるという点で優れています。しかしスフィアは長くて平坦だったり薄い形を表現すること自体には向いていません。それはコーンでも同様です。球体であるスフィアの間には空間ができるのが常だし、最終的にできる集合体はでこぼこになるので、マシンやコーンには別に、それぞれごとのプレーン(面)も必要になるのです。

あるオブジェクトのスフィアセットを他のプレーンでテストしても十分動きますが、残念ながらオブジェクトの並びが入れ替わると矛盾が生じる可能性があります。例えばコーンがマシンのプレーンに対してうまく動いたとしても、その逆はうまくいきません。

我々の問題は、より多くのスフィアを使わないと形状をうまく表せないことと、スフィアとプレーンの二つの異なるコリジョンモデルが必要なこと。これらはいくつか非対称性の問題に繋がるでしょう。

さらに言えば、コリジョンモデルを1つの表現に減らすことができれば、マシン同士の激突に関してクライアントごとの矛盾が少なくなるでしょう。これはみんながネットコードと呼ぶ部分を向上させることになります。

また、我々は高速で壁を突き抜けるスフィアにずっと苦しんでいましたが、今ではコーンがマシンに閉じ込められることもあります。こういった領域も改善したいと思っています。

以下で二つの異なるコリジョンモデルを見ることができます。

What Already Works?

コーンで試して、いくつか大きな変更が必要だと分かっていたので、現時点でうまくいってるものを確認しておくことも道理にかなうでしょう。

iRacing のフィジクスシミュレーションは、典型的なミドルウェアとは異なる独自のもので、一見して分かるものではありませんが現実主義の追求という点において大きな違いがあります。新しく開発する機能はすべて、このスタンスを厳守しなくてはなりません。

iRacing の衝突/コリジョンはよくあるビリヤードゲームのボールのようなものではありません。通常、ビデオゲームでの激突は単純化され、一瞬で考察されます。一つのオブジェクトが別のオブジェクトから跳ね返ると、直ちにその反応が処理され、お互いに向かって動いていたオブジェクトは、いくらかのエネルギー損失とともに、互いに離れていきます。

これは多くのゲームで動きますが、我々が関心のあるケースにおいてはあまりリアルではありません。激突がマシンに即座に作用するなら、プレーヤーが時間内に予測して反応することは難しいです。現実にはマシンは無限の剛性は持ちません。激突には柔軟性も作用しますし、それはもっと時間が掛かります。

これは iRacing が 360Hz という高い周期でフィジクスを走らせたり衝撃力のペナルティメソッドとして知られる実装することで iRacing が得ることのできる重要な現象です。自然界でのペナルティフォースは、複数フレームにわたって衝撃を分散して素材がどのように衝突するか、より多様にモデル化することができます。

また、iRacing に重要なトラック路面は、ドライブできるようスムースだがレーザースキャンで取り込んだ現実のバンプや傾斜を含む十分なディテールが必要です。

多くのゲームはトラックのコリジョンモデルに低い解像度の三角メッシュを使います。iRacing のトラック路面はパラメータによって滑らかなロードセクションとして定義され、別のバンプマップがオーバーレイされています。トラックの全てのディテールは高い忠実性でバンプマップに収められています。

この高解像度は非常に重要で、タイヤモデルが十分なディテールを持ち、トラックの特徴とコースの感触を正確に再現します。

次のページがあります