別のスレッドのシーングラフ


12

私は楽しみのために独自のゲームエンジンを開発しています(利益ではありません)。あるスレッドでレンダリングし、別のスレッドでシーングラフを更新します(速度など)。レンダリングの時間になると、レンダリングスレッドは可視ノードを新しい線形バッファーに追加し、それらをトラバースします。

より詳細には、シーングラフはトリプルバッファリングされています。シーングラフの各ノードには、相対および絶対変換マトリックス(4x4)の3つのコピーがあります。任意の時点で、1つのコピーはシーングラフスレッドによって書き込まれ、1つのコピーはレンダラーによって読み取られ、3つ目のコピーは存在します。これにより、レンダリング中の何かへの書き込みや、半分更新されたシーングラフのレンダリングが防止されます。どういうわけか、ユーザーが更新スレッドと競合しないように作業するために、各マトリックスの4番目のコピーも取得しました。これは、常に同期する必要を回避することでうまく機能するようです。

しかし、これは混乱です。

これらは、システムの私の最終的な目標です。

  • レンダリングとシーングラフの更新は別々のスレッドにとどまります。
  • これらのスレッドが互いに待機する必要がある量を最小限にします。
  • 更新スレッドによって途中で更新されたシーンをレンダリングしないでください。これは、カメラが高速で移動していて、更新の前後にレンダリングされることがある場合に特に顕著です。
  • メモリ使用量の削減。ノードごとに行列が多すぎます。また、マトリックスでの浮動小数点ドリフトの増加により、位置/回転/スケールのベクトルへの移動を検討しています。
  • 数万のノードを処理する機能。現在のシステムはこれをかなりうまくやっています。

また、Bullet(物理エンジン)とネットワークを将来的に組み込むことを望んでいますが、どちらもあまり考えていません。

より良いシーングラフを達成するためのいくつかのアプローチは何ですか?

回答:


4

「ペース」とそのレンダラーに関するヨハネス・スポアの論文を読んだことがありますか?いわゆる「サブミッションエンジン」*並列レンダラーについて説明し、いくつかのアイデアを提供します。

ここでは(ドイツ語)要約ページであり、ここでは英語であるPDFへの直接リンクです。

*:このリンクは、私が最初に論文について聞いた記事にも移動します。)

編集:私はこれを以前にざっと読んだだけで、もう一度見ただけで...シーングラフの詳細が本当に光沢があることに気付きました。私は彼のデザインがいかに直交しているかを知らなかったと思います。特に役に立たない場合は申し訳ありません。


1
この論文の一部はまだ私に突き出ていました:「理想的には、アプリケーションはシーングラフがあることすらまったく知りません。データモデルへの変更を通知する必要があるビューコンポーネントのみを知っている必要があります」。これは私にそれについての新しい考え方にインスピレーションを与えました:シーン全体をトリプルバッファリングする必要はなく、現在のカメラを通して見えるものだけです。カリングをレンダースレッドからシーングラフスレッドに移動して(カメラに遭遇したとき)、いつでもこれら3つのバッファーの1つを書き込み、別のバッファーをレンダラーで読み取ることができます。
EricP

1
-あなたはまた、ゲームエンジン宝石1、及び関連「のDirectX 9とDirectX 10での実用的なパラレル・レンダリング」の記事「カメラ中心マルチスレッドレンダリングのためのエンジンのデザインを」チェックアウトするかもしれないmicrosoft.com/downloads/en/...
Neverender

1
Game Engine Gems 1はオンラインで無料で入手できるようです: books.google.com/…–
EricP
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.