シーングラフにするかしないか？

ゲームにシーングラフを実装するかどうかの決定に苦労してきました。このようなツールを必要とするユースケースはいくつかありますが、実装の詳細の一部を取得できませんでした。

背景：モバイルプラットフォーム（主にAndroid）をターゲットにしたスペースシューティングゲームを書いていて、コードはほぼ完全にC ++です。私はミドルウェアを使用していません。特にレンダリングエンジンと物理エンジンは私自身の作品です。私の物理エンジンは、力と衝撃に基づいてオブジェクトの場所を更新します。私はまだアニメーションシステムを持っていませんが、いつかこれにアクセスする可能性があります（このディスカッションとは関係ない場合もあります）。

まず、良いユースケースについて説明します。複数の個別のパーツで構成されたボスがあり、それぞれが個別に損傷/破壊される可能性があります。たとえば、ボスエンティティの残りの部分とは無関係にダメージを受けるアームを持つボスがあるとします。腕が破壊されると、ボスの肩にある火の粒子の効果は、腕が破壊されたことを示している可能性があります。

現状では、物理エンジンの制約を使用してこのような問題を解決し、このような複合オブジェクトをまとめてみることにしました。そのような制約の1つは自由度0を提供し、本質的に変換行列です。これは、以下に説明するように、最終的に最初にシーングラフを無効にする問題を回避する試みです。

シーングラフの使用を拒否した主な理由は、物理世界とレンダリングシーンの両方でネストされたオブジェクト（親から変換を継承するオブジェクト）を保持する効率的な方法が見つからなかったためです。レンダリングのシーンには親空間のオブジェクトが必要ですが、物理世界ではオブジェクトがワールド空間（または少なくとも同じ空間）にある必要があります。両方のスペースで位置を追跡することは役立つかもしれませんが（避けられないかもしれません）、パフォーマンスに関連するだけでなく、それ自体の懸念を引き起こします。

ただし、上記のようなユースケースを考えると、親スペースで「作業」できることが非常に重要になると思います。制約を使用して物理エンジンにこれらの関係を維持するように強制しようとすると問題が発生します。

上記のユースケースと苦境を踏まえて、あるオブジェクトから別のオブジェクトに変換を渡すためにグラフ構造を使用する必要がありますか？もしそうなら、私の物理エンジンはどのように新しい場所を計算し、異なる空間にあるオブジェクトの交差テストを実行する必要がありますか？

実際に階層グラフを試し、パフォーマンスを測定しましたか？

単純な物理エンジンを調査して、それらが問題をどのように処理するかを確認しました。オブジェクト間のリンケージを持つ2Dエンジンでさえ、実証された方向に導くのに役立ちます。

私はあなたの物理学を複数の空間で実行しようとはしません。ワールドスペースで物理演算を実行し、階層の変換を作成する機能を追加して、ローカルスペースオブジェクトをワールドスペースに移動して戻します。必要な制約は、親オブジェクトを基準にしたローカルスペースにある必要があります。

補足として、オブジェクトの純粋な配列でさえ「シーングラフ」であり、非常に単純なものです。問題を解決する方法でデータを整理することを恐れないでください。特に、そのデータ組織のパフォーマンスは、そのパフォーマンスを測定することさえせずに要因であると決定しないでください。