オブジェクトコンテナーとしてのシーングラフ？

シーングラフには、ゲームオブジェクトを表すゲームノードが含まれています。一見すると、たとえばstd :: vector <>の代わりに、シーングラフをゲームオブジェクトの物理コンテナーとして使用するのが現実的であるように見えるかもしれません。

私の質問は、ゲームオブジェクトを含めるためにシーングラフを使用することは現実的ですか、またはstd :: vector <>などの別のコンテナーに格納されたオブジェクトを保持しながら、シーンオブジェクト/ノードのリンケージを定義するためだけに使用する必要がありますか？

使用するシーン管理のタイプを決定することは、実行しようとしているロジックのタイプに大きく依存します。シーンのさまざまなコンシューマーを考慮してください。

レンダリングコンシューマ

レンダラーはおそらく、任意の時点でユーザーに現在表示されているものを知りたいだけです。高速カリング用のバウンディングボリューム階層が必要です（BVH wikiの記事）。 これにより、ボートの境界が視錐台の外側にあるため、ボート内の椅子を描画する必要がないことがわかります。これはoctreeに埋め込まれている場合があります。

それはまた、椅子がボートの内側の背中にあり、ボートが最終的に見えるようになると、いくつかの波でボートが上下に動いていることを知りたいかもしれません。このようにして、椅子の頂点の最終的な世界座標を見つけることで、椅子とボートの変換を連結し、それを使って処理を行うことができます（これにより、プログラマーとしての作業も簡単になります）。

この問題を見るもう1つの方法は、レンダラーが適切なカードを実行している可能性があり、最終的には、テクスチャ、シェーダー、マテリアル、ライティング、変換状態の変化を最小限に抑えるために、三角形の山を並べ替えることを望んでいることです。このラストは、おそらくパフォーマンス面でBVHよりも役立つでしょう。

ゲームロジック消費者

ゲームロジックは、メッセージングシステムによって互いに通信できるもののフラットリストを必要とするだけなので、std :: vectorで十分です。

ゲームはまた、誰が何に最も近いかを追跡する方法を必要とする場合があるため、そのような場合、ある種の[最も近い] [3]情報が役立つ場合があります。これはBVHでも提供できますが、グラフを上下に移動しなければならないのは面倒です。

ゲームは、Aを移動すると、AのアイテムBも移動することを知りたいだけかもしれません。その場合、一種の変換階層に戻ります。

物理学の消費者

ゲームの物理学では、非常に高速な衝突検出のために、屋内空間の[特別な表現] [4]が必要になる場合があります。あるいは、衝突する可能性のあるものを効率的に見つけるために、ある種のoctreeまたは[空間ハッシュ] [5]を使用する場合があります。

上記の物理データ構造はどれも、Java3Dの意味で「シーングラフ」のようには見えません。

オーディオ消費者

オーディオエンジンは、サウンドの減衰と伝搬を計算するために、ジオメトリ、おそらく潜在的に表示される（可聴）セット、または何らかの境界ボリューム階層を必要としています。繰り返しになりますが、シーンのジオメトリのグラフである可能性もありますが、実際には通常の種類のシーングラフではありません。

最終的には... ...実際のアプリケーションのニーズによって異なります。まず、フラットリストを使用して、問題が発生する場所を確認することをお勧めします。変換の階層を持つフラットリストを試すこともできます。これは、効率以外の理由で役立つ1種類のシーングラフであるためです。

幸運を！

ゲームオブジェクトのコンテナとしてシーングラフを使用しない理由は1つあります。それはインスタンス化です。一部のリソースを再利用する場合は、実際のコピーを複数持つよりも、シーングラフからリソースを数回参照するほうがはるかに理にかなっています。

オブジェクトモデルとビューモデル（シーングラフ）を分離することは、通常は良い考えです。

この件に関する記事をご覧ください。

これにより、オブジェクトプールを使用できるようになります。これは、効率的なメモリ管理に不可欠です。