物理シミュレーションと異なる座標系との接続

オブジェクトが「ウィンドウ」を介して2つの物理シミュレーションの間を移動し、ウィンドウプレーンと交差する場合に両方のシミュレーションのオブジェクトと衝突するようにします。

シミュレーションの座標系は同じ原点を持たず、向きが異なる場合があります。シミュレーションをそれ自体にラップする必要はありませんが、プラスになります。

個々のオブジェクトを複製せずにシステムを効率的に接続するにはどうすればよいですか？

編集：

計算は可能な限り正確でなければならないので、オブジェクトが反対側から同時にウィンドウを横切ってもオブジェクトが動かなくなることはありません。

以前は 'Portalized'と呼ばれていた、Pseudoformと呼ばれるこのクールなプロジェクトがあり、これは、ポータルを使用して物理シミュレーションをグルービー形式で処理します。

シュードフォーム

見てみな！

特にビデオ-それは驚異的にクールです。

それはオープンソースなので、彼らがどうやってそれをやっているか見ることができます。

きっとあなたが望んでいることでしょう。:)

わかりました-これが機能するかどうかはわかりません。
上記の情報に基づいて、「ウィンドウ」にトリガーを配置して、オブジェクトが世界から出て行く時期を検出できるようにします。衝突時の現在の速度ベクトルを取得します。トリガーが当たった場所と、このフレームが終了した場所に基づいて、残りのタイムステップを計算します（世界外では、これを可能にするために仮想境界が必要になります）。この時点で、速度と残りのタイムステップがわかっているので、入力しようとしている世界の境界に再配置して、速度を再投影できます。ただし、これには1つのフレームで2つの物理演算の更新が必要であり、同じ位置で別のオブジェクトがbからaに移動するときに、aからbに移動するオブジェクトの境界線があり、衝突はまったく検出されません。
ちょっと大ざっぱ、

物理シミュレーションに関するいくつかの情報を読み、可能な解決策を見つけました。各物理ステップを3つのフェーズに分割することで機能します。

1.事前ステップ：

物理ステップごとに、ウィンドウは4つの変換を作成し、2つは接続の両側にあります。

• オブジェクトの位置、速度（およびおそらくサイズと重量）を目的の座標系に変換する入力変換
• 力を変換してオブジェクトの元のシステムに戻す出力変換。

（静的ウィンドウはこれを一度だけ行う必要があります。）

さらに、各座標系のオブジェクトは3つのグループに分けられます。

物理グループhttp://content.wuala.com/contents/Tamschi/Stack%20Exchange/WindowGrouping.png

1. ウィンドウの前面にあるオブジェクト（緑）。
   オブジェクトがウィンドウ平面と交差している場合、またはウィンドウの後ろから交差する可能性がある場合（図示せず）も、このグループにカウントされます。

2. この物理ステップ（オレンジ色）でウィンドウと交差する、またはウィンドウと交差する可能性が高いオブジェクト。

3. ウィンドウの後ろのオブジェクト（青）。オブジェクトがウィンドウの背面に向かって飛ぶ場合でも、グループ3のメンバーとしてマークされます。

ウィンドウがシミュレーションの境界にある場合、グループ化を簡略化できます。

2.メインステップ：

物理演算は、いくつかの例外を除いて、通常どおりに計算されます。

• 2番目のグループのオブジェクトが3番目のグループのオブジェクトと衝突することはありません。逆も同様です。

• ウィンドウの入力変換は2番目のグループのオブジェクトで使用され、結果は宛先システムの前面および交差するオブジェクトに対して評価されます。結果として生じる力は、出力変換を使用して変換され、元のオブジェクトに適用されます。

（オブジェクトが計算中にヒットした場合、再グループ化する必要があります！）

3.後手順：

2番目のグループのオブジェクトがウィンドウを通過した場合は、入力変換を使用して宛先システムに移動されます。

追加の考え：

物理演算後に変換が保持される場合は、変換を使用してレンダリングを高速化し、AI計算を簡単にすることができます。グループ化を使用して、レンダリングプロセスからクリップ面を削除できます。

このソリューションの欠点は、ウィンドウを物理エンジンに直接追加する必要があることです。