ゲーム内のグラフィックスエンジンと物理エンジンの間でデータを共有する必要がありますか?


9

いくつかのモジュールで構成されるゲームエンジンを書いています。それらの2つは、グラフィックエンジン物理エンジンです。

それらの間でデータを共有することは良い解決策ですか?

2つの方法(共有かどうか)は次のようになります。

データを共有せずに

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

主な問題が2つあります。

  1. 大量の冗長データ(物理データとグラフィックデータの両方の2つの位置など)
  2. データの更新に関する問題(物理データが変更された場合、グラフィックスデータを手動で更新する必要があります)

データ共有あり

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assingModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

ここでの問題:

  1. physicsEngineは新しいオブジェクトを作成できません。engine3Dから既存のオブジェクトを「アッシング」するだけです(どういうわけか、私にとってはより独立していないように見えます)。
  2. assingModel3D関数でのデータのキャスト
  3. physicsEngineとgraphicsEngineは注意する必要があります。必要がない場合はデータを削除できません(2番目のデータが必要になる可能性があるため)。しかし、それはまれな状況です。さらに、オブジェクトではなくポインタのみを削除できます。または、graphicsEngineがオブジェクトを削除すると仮定することもできます。physicsEngineはそれらへのポインタだけです。

どっちがいい?

将来、より多くの問題が発生するのはどれですか?

私は2番目のソリューションがもっと好きですが、ほとんどのグラフィックスエンジンと物理エンジンが最初のソリューションを好むのはなぜだろうと思います(通常、グラフィックスのみまたは物理エンジンのみを作成し、他の誰かがゲームでそれらを接続するためでしょうか?)。

彼らはもう隠れた賛否両論を持っていますか?


まさに私の質問も。
danijar

回答:


9

最近では、より多くのゲームエンジンがコンポーネントデザインを採用しています(Unity、Unrealなど)。この種の設計でGameObjectは、a はコンポーネントのリストで構成されます。あなたの状況では、MeshComponentとがありPhysicalComponent、どちらも単一のゲームオブジェクトにアタッチできます。

簡単にするために、ワールド変換変数をに配置できますGameObject。フレーズの更新時にPhysicalComponent、ワールド変換をその変数に出力します。レンダリング中に、はMeshComponentその変数を読み取ります。

この設計の背後にある理論的根拠は、コンポーネント間の分離です。どちらMeshComponentPhysicalComponentお互いを知りません。それらは共通のインターフェースに依存しています。また、単一の継承階層を使用するよりも、構成によってシステムを拡張する方が簡単です。

ただし、現実的なシナリオでは、物理/グラフィック同期間のより高度な処理が必要になる場合があります。たとえば、レンダリングを可変にする必要がある一方で、物理シミュレーションは固定時間ステップ(たとえば30Hz)で実行する必要がある場合があります。そして、物理エンジンの出力からの結果を補間する必要があるかもしれません。ただし、一部の物理エンジン(Bulletなど)は、この問題を直接サポートしています。

Unityは、それらのComponentsの優れたリファレンスを提供しており、一見の価値があります。


これは質問にはまったく答えません。2つのコンポーネントがあると、それらがメッシュデータを共有するかどうかについては何も言えません。
Maik Semder

2
実際には、それは完全に合法であるより良いデザインを提供します。
jcora

7

エンジンは、品質と量の両方で非常に異なるデータを必要とするため、通常、最初のオプション(独自の物理メッシュと独自のレンダリングメッシュ)を選択します。

品質は、物理エンジンがテクスチャ座標、通常のグループ、およびこのすべての派手なレンダリングなどを気にしないためです。それらのそれぞれは、非常に特定のレイアウトのデータが配置の問題、パッキング、データのインターリーブなどに至ることを期待しています。

数量:物理メッシュには通常、三角形の数が少ないため、高解像度のレンダリングメッシュの簡易バージョンです。

両方を分離することで、データレイアウトを変更してパフォーマンスを向上させ、もう一方を破損させることなく、一方を確実にテストできるようにします。よりスケーラブルです。


0

@Millo Yipのすばらしい回答の他に、同じデータをControlsモジュールとAIモジュールで共有する必要があることを思い出させてください。そのため、そのモジュールでもデータを共有する必要があります。


0

他の人が言ったように、物理学が内部データの状態をレンダリングエンジンの内部データの状態とは別に管理しているのは、かなり一般的な場所です。多くの場合、物理オブジェクトとレンダリング可能オブジェクトの両方とは別に保存されている変換データ(位置/向き/スケール)でさえ見ることが一般的です。これは、物理オブジェクトによって強制されたりレンダリングされたりせず、他のメカニズムのワールド位置を必要とするゲームオブジェクトが存在する可能性があるためです。

データが物理学からレンダリング可能になる方法は完全にあなた次第です。

イベント/メッセージを使用して、サブシステム間のディスパッチプロセスを介してこれを行うことができます。これを行うには、レンダリングサブシステムのパブリックインターフェイスを物理サブシステムに公開して、物理が特定のレンダリング可能オブジェクトの位置を簡単に設定できるようにします。別のオプションは、Renderable Subsystemが更新中にエンティティの変換をクエリし、Renderableコンポーネントの位置を更新してから描画を行うことです。

当然、ゲームによっては、これらの手段のいくつかは他の手段よりもキャッシュフレンドリーで、パフォーマンスが優れています。この時点では、特定の方法にあまり夢中にならず、コミュニケーションパターンを選んで試してみませんか。後でこの部分を簡単にやり直して、最適化のためのさまざまな手段をテストできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.