09/07/23 22:31:03 QnjM8dUv0
>1-4
●コンポジション1
Ｌトラック1
Ｌトラック2
●コンポジション2
Ｌトラック3
Ｌトラック4
のようなケースで、コンポジションだと
・トラック4、トラック3を描画して画像化→コンポジション2になる
・トラック2、トラック1を描画して画像化→コンポジション1になる
・コンポジション2、コンポジション1を描画
のように、一旦画像にするという過程があるのでコンポジションだと僅かながらパフォーマンスが低下するかと。
（フォルダはコンポジションのようにエフェクトをかけられないが、その分画像化がなくて高速）
コンポジ2つぐらいだったらほとんど変化無いかもしれませんが、もっとあったら顕著に現れると思います。
使いづらいから要らないというのはどうしようもないですが・・。
＞一つのフォルダにまとめてしまうとその関係が崩れてしまう
・・・すいません、どんな時に問題が生じるのでしょうか？他のトラックから参照されているトラックをフォルダに入れたりしたとき？
データ構造的にはLinkedListからCompositeパターン使った木構造に変わると思いますがそんな問題が起きるのでしょうか。
現在のNiVEでフォルダ等使わず描画するのとトラックの処理の順番は変わらない気がしますが。
>2-4
私が考えていたのは
画像を扱うクラスにOpenGLのテクスチャとメインメモリの画像の内容が一致しているかを設定/取得する機能をつけることです。
（メインメモリからテクスチャにアップロードが必要、テクスチャからメインメモリにダウンロードが必要、どちらも必要も無い のように）
転送を本体がやるのか、エフェクトの前処理でやるのかとかという問題もありますが。
1つのOpenGLコンテキストを全てのOpenGLを使ったエフェクトで共有するのではなく、コンテキストは別々にして、作成時に
必ずディスプレイリストを共有するようにする方がいいと思います。マルチウィンドウやマルチスレッドのときはそうするので。
＞プログラムごと落ちる
→前のエフェクトでテクスチャが作成されていないのにあると勘違いした時？
＞レンダリングイメージが不正
→テクスチャが作成されていると勘違いし、プログラムは落ちなかったが白い画像が表示されるとか
→テクスチャからメインメモリに転送するのを忘れて処理前のイメージが表示されてしまったりとか？
>2-6
浮動小数フォーマットで画像を保持することが出来ないので浮動小数を整数型にエンコードすることで
浮動小数を使わずHDRレンダリングをしようという事だったのですが、なぜ画像形式とかの話に・・（保存とか言ったせい？）
RGBE8を使った画像フォーマットでRadiance形式というのがあることはありますが。
URLﾘﾝｸ(msdn.microsoft.com)
URLﾘﾝｸ(ja.wikipedia.org)ハイダイナミックレンジイメージ
でも浮動小数なしだとやっぱりHDRレンダリングはやりにくいです。出来なくはなさそうですが。
>2-7
ポストプロセスって、半透明ソートとかですか？オブジェクト単位のソートなら描画順を変えるだけでいいですが
GLSLを使う場合はやりづらそうですね・・
一つのエフェクトに描画する3Dモデルなどを追加していく方式にするしかないのでしょうか。
＞2-14
そういえばNiVEは一つのDLLに沢山エフェクトが入っていたんでした・・
入っているフォルダで管理する方式が使えないとなると、設定でカテゴリを変更するエフェクトを登録するしかなさそうです。
これだとやりづらいかな・・
サブカテゴリは区切り記号でも設定しておけば出来そうですが、どうでしょうか。