タグ付けされた質問 「scene-graph」

こんにちは、Game Development SE！ 私は、シンプルで非常に軽量なゲームエンジンを作成することを期待して、OpenGLを駆け巡っています。私はこのプロジェクトを、最終的には少しお金を稼ぐかもしれないが、どちらにしても楽しい学習体験だと思っています。 これまで、GLFWを使用して、基本的なI / O、ウィンドウ（非常に派手なF11フルスクリーンキー）、そしてもちろんOpenGLコンテキストを取得しました。また、GLEWを使用して、残りのOpenGL拡張機能を公開しました。これは、Windowsを使用しており、OpenGL 3.0+をすべて使用するためです。 これでシーングラフが表示されます。要するに、私は自分で転がしたいと思います。この決定は、OSGを見て、シーングラフの概念がどのようにねじれ、曲がり、壊れたのかに関するいくつかの記事を読んだ後に決定されました。そのような記事の 1 つでは、シーングラフがどのように開発されているかを説明しています... 次に、クリスマスツリーに飾りを吊るすなど、これらすべての余分なものを追加しました。ただし、飾りの一部はジューシーなステーキで、一部は生きた牛全体です。 類推に続いて、余分なコードの山や牛全体を縛る必要なしに、ステーキ、シーングラフがどうあるべきかの肉が欲しいです。 それで、それを念頭に置いて、私はシーングラフがどうあるべきか、単純なシーングラフをどのように実装すべきかを正確に疑問に思っていますか？ここに私が持っているものがあります... 1つの親、n子ツリーまたはDAG ... ゲームオブジェクトの変換（位置、回転、スケール）を追跡する必要があります 最適化のためにレンダリング状態を保持する必要があります ビュー錐台内にないオブジェクトを選別する手段を提供する必要があります 次のプロパティで... すべてのノードはレンダリング可能として扱われる必要があります（レンダリングしない場合でも）これは、... すべてにcull（）、state（）、draw（）メソッドが必要です（非表示の場合は0を返します） cull（）は、すべての子に対して再帰的にcull（）を呼び出し、ノード全体およびすべての子に対して完全なカリングメッシュを生成します。もう1つのメソッドhasChanged（）を使用すると、いわゆる静的メッシュでカリングジオメトリを各フレームで計算する必要がなくなります。これは、サブツリー内のノードが変更された場合、ルートまでのすべてのジオメトリが再構築されるように機能します。 レンダリング状態は単純な列挙で保持され、各ノードはこの列挙から必要なOpenGL状態セットを選択し、そのノードでdraw（）が呼び出される前に状態がセットアップされます。これにより、バッチ処理が可能になり、指定された状態セットのすべてのノードが一緒にレンダリングされ、次の状態セットがセットアップなどになります。 ジオメトリ/シェーダー/テクスチャデータを直接保持するノードはありません。代わりに、ノードは共有オブジェクト（リソースマネージャーなどのシングルトンオブジェクトによって管理される可能性があります）を指す必要があります。 シーングラフのような状況可能にするために（多分プロキシノードを使用して）他のシーングラフを参照することができる必要があり、これをこのように複雑なマルチメッシュモデルを可能にする、/データのトンを追加することなく、シーングラフの周りにコピーするオブジェクト。 現在の設計について貴重なフィードバックを得たいと思っています。機能がありませんか？非常に優れた方法/デザインパターンはありますか？ややシンプルな3Dゲームのために、このデザインに含める必要のあるより大きなコンセプトがありませんか？等。 ありがとう、コーディ

23 opengl  3d  scene-graph 

私のゲームには、プレイヤーで神風が爆発するモンスターがいるとしましょう。このモンスターの名前をランダムに選んでみましょう：クリーパー。そのため、Creeperクラスには次のようなメソッドがあります。 void Creeper::kamikaze() { EventSystem::postEvent(ENTITY_DEATH, this); Explosion* e = new Explosion; e->setLocation(this->location()); this->world->addEntity(e); } イベントはキューに入れられず、すぐにディスパッチされます。これにより、Creeperの呼び出し内のどこかでオブジェクトが削除されますpostEvent。このようなもの： void World::handleEvent(int type, void* context) { if(type == ENTITY_DEATH){ Entity* ent = dynamic_cast<Entity*>(context); removeEntity(ent); delete ent; } } Creeperオブジェクトはkamikazeメソッドの実行中に削除されるため、にアクセスしようとするとクラッシュしますthis->location()。 1つの解決策は、イベントをバッファにキューイングし、後でそれらをディスパッチすることです。それはC ++ゲームの一般的なソリューションですか？それはちょっとしたハックのように感じますが、それは異なるメモリ管理プラクティスを持つ他の言語での私の経験のためかもしれません。 C ++では、オブジェクトがそのメソッドの1つから誤って自分自身を削除するこの問題に対するより一般的な解決策はありますか？

20 c++  scene-graph 

私は楽しみのために独自のゲームエンジンを開発しています（利益ではありません）。あるスレッドでレンダリングし、別のスレッドでシーングラフを更新します（速度など）。レンダリングの時間になると、レンダリングスレッドは可視ノードを新しい線形バッファーに追加し、それらをトラバースします。 より詳細には、シーングラフはトリプルバッファリングされています。シーングラフの各ノードには、相対および絶対変換マトリックス（4x4）の3つのコピーがあります。任意の時点で、1つのコピーはシーングラフスレッドによって書き込まれ、1つのコピーはレンダラーによって読み取られ、3つ目のコピーは存在します。これにより、レンダリング中の何かへの書き込みや、半分更新されたシーングラフのレンダリングが防止されます。どういうわけか、ユーザーが更新スレッドと競合しないように作業するために、各マトリックスの4番目のコピーも取得しました。これは、常に同期する必要を回避することでうまく機能するようです。 しかし、これは混乱です。 これらは、システムの私の最終的な目標です。 レンダリングとシーングラフの更新は別々のスレッドにとどまります。 これらのスレッドが互いに待機する必要がある量を最小限にします。 更新スレッドによって途中で更新されたシーンをレンダリングしないでください。これは、カメラが高速で移動していて、更新の前後にレンダリングされることがある場合に特に顕著です。 メモリ使用量の削減。ノードごとに行列が多すぎます。また、マトリックスでの浮動小数点ドリフトの増加により、位置/回転/スケールのベクトルへの移動を検討しています。 数万のノードを処理する機能。現在のシステムはこれをかなりうまくやっています。 また、Bullet（物理エンジン）とネットワークを将来的に組み込むことを望んでいますが、どちらもあまり考えていません。 より良いシーングラフを達成するためのいくつかのアプローチは何ですか？

12 multithreading  scene-graph 

gitにコミットする前に、シーン（.unityファイル）に加えられた変更を確認したいと思います。 私はいくつかのGIT / Unityソリューションを調べましたが、それらはすべて変更をマージするために作成されたものであり、最新バージョンとの差分を表示するためのものではありません。 シーンファイルの問題は、他のアセットを指すGUIDを使用することであり、シーンファイルの差分を開くと、実際には何も作成できません。 例えば： 代わりに、私はこのようなものを見たいのですが： これを行うものは存在しますか？

11 unity  scene-graph  scene  version-control 

バックグラウンド： 私は、C ++とOpenGLを使用して、エンティティコンポーネントシステムタイプアーキテクチャ用のシンプルな3Dレンダリングシステムを設計しています。システムは、レンダラーとシーングラフで構成されています。レンダラーの最初の反復を終えたら、シーングラフをECSアーキテクチャーに配布します。今のところ、それは何らかの方法でプレースホルダーです。可能であれば、レンダラーの目標は次のとおりです。 シンプルさ。これは研究プロジェクト用であり、システムを簡単に変更および拡張できるようにしたい（したがって、ECSアプローチ）。 パフォーマンス。私のシーンには、多くの小さなモデルと、多くのジオメトリを持つ大きなボリュームがあるかもしれません。OGLコンテキストからオブジェクトを取得し、レンダリングフレームごとにジオメトリをバッファリングすることはできません。キャッシュミスを回避するために、データの局所性を目指しています。 柔軟性。スプライト、モデル、ボリューム（ボクセル）をレンダリングできる必要があります。 分離。レンダラーを作成した後、シーングラフがコアECSアーキテクチャにリファクタリングされる場合があります。 モジュラー。シーングラフを変更せずに、さまざまなレンダラーを入れ替えることができると便利です。 参照透明度、つまり、いつでも有効なシーンを指定できるため、そのシーンでは常に同じ画像がレンダリングされます。特にこの目標は必ずしも必要ではありません。シーンのシリアル化を簡略化し（シーンの保存と読み込みができるようにする必要があります）、テスト/実験の目的で実行時に異なるシーンを入れ替える柔軟性が得られると思いました。 問題とアイデア： 私はいくつかの異なるアプローチを考え出しましたが、各レンダリングノードのOGLリソース（VAO、VBO、シェーダーなど）をキャッシュする方法に苦労しています。以下は、これまでに考えてきたさまざまなキャッシングの概念です。 一元化されたキャッシュ。各シーンノードにはIDがあり、レンダラーにはIDをレンダリングノードにマップするキャッシュがあります。各レンダーノードには、ジオメトリに関連付けられたVAOとVBOが含まれています。キャッシュミスはリソースを取得し、ジオメトリをキャッシュ内のレンダーノードにマップします。ジオメトリが変更されると、ダーティフラグが設定されます。レンダラーがシーンノードを反復処理しているときにダーティジオメトリフラグを確認すると、レンダラーを使用してデータを再バッファーします。シーンノードが削除されると、イベントがブロードキャストされ、レンダラーは関連するレンダーノードをキャッシュから削除し、リソースを解放します。または、ノードに削除のマークが付けられており、レンダラーがノードを削除する責任があります。このアプローチは、4と5も考慮しながら、最も厳密に目標6を達成すると思います。2は、配列アクセスの代わりにマップルックアップを使用すると、複雑さが増し、データの局所性が失われます。 分散キャッシュ。上記と同様ですが、各シーンノードにはレンダーノードがあります。これにより、マップルックアップがバイパスされます。データの局所性に対処するために、レンダーノードをレンダラーに保存できます。その場合、シーンノードは代わりにレンダリングノードへのポインターを持つことができ、レンダラーはポインターをキャッシュミスに設定します。この種のエンティティコンポーネントアプローチを模倣しているので、アーキテクチャの他の部分と一貫性があると思います。ここでの問題は、シーンノードがレンダラー実装固有のデータを保持することです。レンダラでのレンダリング方法を変更する場合（スプライトとボリュームのレンダリングなど）、レンダーノードを変更するか、シーンノードに「コンポーネント」を追加する必要があります（つまり、シーングラフも変更します）。プラス面では、これは、最初の反復レンダラーを起動して実行する最も簡単な方法のようです。 分散メタデータ。レンダラーキャッシュメタデータコンポーネントは、各シーンノードに格納されます。このデータは実装固有ではなく、ID、タイプ、およびキャッシュに必要なその他の関連データを保持しています。次に、IDを使用して配列内で直接キャッシュルックアップを実行できます。タイプは、使用するレンダリングアプローチのタイプ（スプライトとボリュームなど）を示します。 訪問者+分散マッピング。レンダラーはビジターであり、シーンノードはビジターパターンの要素です。各シーンノードは、レンダラーのみが操作するキャッシュキー（メタデータのようにIDのみ）を保持します。IDは、一般化されたマップ検索の代わりに配列に使用できます。レンダラーを使用すると、シーンノードのタイプに基づいてシーンノードが異なるレンダリング関数をディスパッチでき、IDは任意のキャッシュで使用できます。デフォルトまたは範囲外のIDは、キャッシュミスを示します。 この問題をどのように解決しますか？それとも何か提案はありますか？私のテキストの壁を読んでくれてありがとう！

10 architecture  rendering  entity-system  scene-graph 

OpenGL ES 2.0（現在のところiOS）を使用して2Dゲームエンジンを作成しようとしています。私は、Objective Cでアプリケーション層を記述し、C ++で別の自己完結型のRendererGLES20を記述しました。レンダラーの外部ではGL固有の呼び出しは行われません。完全に機能しています。 しかし、シェーダーを使用する際にいくつかの設計上の問題があります。各シェーダーには、メインの描画呼び出しの直前に設定する必要のある独自の固有の属性とユニフォームがあります（この場合はglDrawArrays）。たとえば、いくつかのジオメトリを描画するには、次のようにします。 void RendererGLES20::render(Model * model) { // Set a bunch of uniforms glUniformMatrix4fv(.......); // Enable specific attributes, can be many glEnableVertexAttribArray(......); // Set a bunch of vertex attribute pointers: glVertexAttribPointer(positionSlot, 2, GL_FLOAT, GL_FALSE, stride, m->pCoords); // Now actually Draw the geometry glDrawArrays(GL_TRIANGLES, 0, m->vertexCount); // …

10 opengl  shaders  scene-graph  pipeline 

ゲームにシーングラフを実装するかどうかの決定に苦労してきました。このようなツールを必要とするユースケースはいくつかありますが、実装の詳細の一部を取得できませんでした。 背景：モバイルプラットフォーム（主にAndroid）をターゲットにしたスペースシューティングゲームを書いていて、コードはほぼ完全にC ++です。私はミドルウェアを使用していません。特にレンダリングエンジンと物理エンジンは私自身の作品です。私の物理エンジンは、力と衝撃に基づいてオブジェクトの場所を更新します。私はまだアニメーションシステムを持っていませんが、いつかこれにアクセスする可能性があります（このディスカッションとは関係ない場合もあります）。 まず、良いユースケースについて説明します。複数の個別のパーツで構成されたボスがあり、それぞれが個別に損傷/破壊される可能性があります。たとえば、ボスエンティティの残りの部分とは無関係にダメージを受けるアームを持つボスがあるとします。腕が破壊されると、ボスの肩にある火の粒子の効果は、腕が破壊されたことを示している可能性があります。 現状では、物理エンジンの制約を使用してこのような問題を解決し、このような複合オブジェクトをまとめてみることにしました。そのような制約の1つは自由度0を提供し、本質的に変換行列です。これは、以下に説明するように、最終的に最初にシーングラフを無効にする問題を回避する試みです。 シーングラフの使用を拒否した主な理由は、物理世界とレンダリングシーンの両方でネストされたオブジェクト（親から変換を継承するオブジェクト）を保持する効率的な方法が見つからなかったためです。レンダリングのシーンには親空間のオブジェクトが必要ですが、物理世界ではオブジェクトがワールド空間（または少なくとも同じ空間）にある必要があります。両方のスペースで位置を追跡することは役立つかもしれませんが（避けられないかもしれません）、パフォーマンスに関連するだけでなく、それ自体の懸念を引き起こします。 ただし、上記のようなユースケースを考えると、親スペースで「作業」できることが非常に重要になると思います。制約を使用して物理エンジンにこれらの関係を維持するように強制しようとすると問題が発生します。 上記のユースケースと苦境を踏まえて、あるオブジェクトから別のオブジェクトに変換を渡すためにグラフ構造を使用する必要がありますか？もしそうなら、私の物理エンジンはどのように新しい場所を計算し、異なる空間にあるオブジェクトの交差テストを実行する必要がありますか？

10 scene-graph  graph  architecture 

学習課題として、遅延レンダリングエンジンを作成しました。このエンジンにシーングラフを追加したいのですが、その方法に少し戸惑っています。 通常の（フォワードレンダリングエンジン）では、すべての項目（すべてIDrawableとIUpdateAbleを実装）をシーングラフに追加するだけで、最初にシーングラフの幅を移動し、どこにでもDraw（）を呼び出します。 ただし、遅延レンダリングエンジンでは、描画呼び出しを分離する必要があります。すべてを組み合わせる前に、まずジオメトリを描画し、次にシャドウキャスター、次にライト（すべて異なるレンダーターゲットに対して）を描画する必要があります。したがって、この場合、シーングラフ上を移動して、drawを呼び出すだけでは済みません。私の見方では、シーングラフ全体を3回移動して、描画する必要があるオブジェクトの種類を確認するか、何らかの方法で相互に接続された3つの個別のシーングラフを作成する必要があります。これらはどちらも貧弱なソリューションのようですが、シーンオブジェクトをより透明に処理したいと考えています。 私が考えていたもう1つの解決策は、通常どおりシーングラフを移動し、アイテムを3つの個別のリストに追加し、ジオメトリ、シャドウキャスター、ライトを分離し、これらのリストを反復して正しいものを描画することでした。フレームごとに3つのリストを再入力するのは賢明ですか？

10 xna  c#  scene-graph 

ゲームシーングラフ内に正確に何を含める必要があるかを明確にしていただけませんか。次のリストをご覧ください。 ゲーム俳優？（当然のことながら、状態を変更するすべてのオブジェクトは、シーングラフの主要な部分である必要があります） 単純な静的ゲームオブジェクト （つまり、アニメーション化されない、または衝突しないバックグラウンドの場所を除外します） ゲームトリガー？ ゲームライト？ ゲームカメラ？ 武器弾丸？ ゲームの爆発と特殊効果？ 上記で検討したオブジェクトタイプ。次に、シーングラフのカバレッジに進みます。 シーングラフには、レベルの開始以降のゲームレベルマップ全体を含める必要がありますか、それともマップの表示部分のみを含める必要がありますか？2番目がtrueの場合、プレイヤーが移動するときに、ゲームオブジェクトを追加または削除することにより、シーングラフが継続的に更新されます。ただし、マップの可視領域のみを含めると、トラバースと更新がはるかに高速になります。

10 game-design  architecture  scene-graph 

私は、最近ゲーム開発に興味を持ち始めた7年以来、Java Webアプリケーション開発者（主にサーバー側）です（理由はわかりませんが、おそらく退屈です）。今日、私はフレームワークを探していました。いくつかのシーングラフについて読み、jMonkeyEngineを調べました。こことここがお勧めです。 私の最初の目標は、キーボードを使用して移動できる単純な平面と球を作成することでした。さて、先ほど触れたように、私はWeb開発者であり、他に何もプログラミングしたことがないので、jMonkeyのチュートリアルから始めました。しかし、私はそれらを機能させることができませんでした。私はウィキを調べましたが、少なくとも私が慣れているものと比較して、ドキュメントが非常に貧弱であるように見えました。次に、他のいくつかのシーングラフ（これもC ++の場合）を調べましたが、古くて不完全な不十分なドキュメントもあるようです。 誰かが私に実用的なサンプルが十分に文書化されているシーングラフを勧めることができますか？または、このトピックに入る「究極のガイド」のようなものはありますか？最初に自分のシーングラフを作成して機能させる方法を知る必要がありますか、それとも抽象的な原則を理解して、より高い視点からそれを使用することは可能ですか？ どういうわけか私はそれをうまく使用するためにシーングラフの内部を理解する必要があると感じています（Web開発のORMツールの場合のように、データベースを理解しないとそれらをうまく使用できません） この質問があまりにも「無意味」である場合は申し訳ありませんが、ただ立ち上がって最初のステップを実行したいだけです。

8 scene-graph 

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

8 architecture  scene-graph 

まだシーングラフを実装しています（この質問を参照）。さて、Kd-TreeやOctreeなどの空間表現でビュー錐台カリング（VFC）を行うのは、静的なジオメトリでのみ意味があるのでしょうか。私の疑問の理由は、通常、動的なジオメトリはシーンの小さな部分ですが、静的なジオメトリは非常に大きくなる可能性があり、動的なジオメトリは各フレームで空間表現の更新を強制的に処理するためです。 あなたの意見は？ トゥヌズ

7 performance  scene-graph