4

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

それらの間でデータを共有することは良い解決策であるかどうか疑問に思いますか？

2つの方法（共有するかどうか）は次のようになります。

データを共有せずに

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

    //some only graphic data 
    //like textures and detailed model's vertices 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 information 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->assignModel3D(&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. AssignModel3D関数でのデータのキャスト
  3. physicsEngineまた、graphicsEngine注意が必要です。データが不要な場合は削除できません（2番目のデータが必要になる可能性があるため）。しかし、それはまれな状況です。さらに、オブジェクトではなく、ポインタを削除するだけで済みます。または、オブジェクトへのポインタだけgraphicsEngineで、オブジェクトが削除されると想定することもできます。physicsEngine

どちらが良いですか？

将来、どちらがより多くの問題を引き起こすでしょうか？

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

彼らにはこれ以上隠された長所と短所がありますか？

4

1 に答える 1

5

現在、より多くのゲームエンジンがコンポーネントデザインを採用しています（Unity、Unrealなど）。この種の設計では、aGameObjectはコンポーネントのリストで構成されます。あなたの状況では、aMeshComponentとaがありPhysicalComponent、両方とも単一のゲームオブジェクトにアタッチされています。

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

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

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

Unityは、一見の価値のあるコンポーネントの優れたリファレンスを提供しました。

于 2012-11-21T09:27:26.523 に答える