もきもき3D

アクセスカウンタ

zoom RSS ShaderClassとVPR

<<   作成日時 : 2011/07/04 18:22   >>

なるほど(納得、参考になった、ヘー) ブログ気持玉 1 / トラックバック 0 / コメント 0

DStormの方にも書いたけど、こちらでは愚痴も織り交ぜてお送りします(・з・)Newtekのホビロン!
10.0での話。10.1ではまた何か変わってくるかも。

□ShaderClassの流れ。

○Previewr。
 Cleanup()→Init()→Newtime()→Evaluate()
 後処理が最初に行われる謎仕様。 Previe→Renderと続く場合を考えて、Initでも後処理が必要になる。

○Render。
 Init()→{Newtime()→Evaluate()}→{...}→Cleanup()
 マニュアル通りの順当な動作。

○VPR。
 Evaluate()
 規定の動作を端折りながらも注意書きの一つもない自分勝手な動作(・з・)Newtek氏ね!


□VPRの特記点。
1)Init/Newtime/Cleanupを呼ぶ事はない(※1)。
 これらで前処理をし、それに依存する場合、VPRでは不正な結果になるしかない。

 Evaluateだけで完結する必要がある為、Eval毎に全ライトを走査/判定する事になり、本レンダリング時は速度面で足を引っ張る。
 モデラにはItemInfoが無いのでライトのリストは取れない、その為のダミーID((void*)1)挿入をEvaluate毎に行うという馬鹿げた処理が致命的。
 ※一応、モデラとレイアウトの差異への対応はHandler()の段階で判別して、Evaluate関数を差替える事で対処は出来る(バイナリが倍増するけど)。
 上記の様にInitやNewtimeで処理すれば一度で済む事(任意時間において結果が普遍な処理)を無駄に繰り返す事なる。

 Preview時のCleanupが不適切な為、Initの稼動をフラグとしてEvaluateで分岐させる事も出来ない(Cleanupで初期状態に復帰出来ない為)。

 Newtimeが呼ばれないので、現時刻を知るには別途TimeInfoを経由した時間取得が必要になる(※1)。

2)出力先のBufferは事前に初期化されない(っぽい)。
 Shaderの重ねがけを考慮して、既存のBuffer値(Replace/Shadding)を参照している場合は問題になる。
 既存のBufferに上書きをする(他のShaderClass適用を認めていない)なら問題にはならない。
 NodeClassの場合は常に終端ノードに上書きで挿入する事になるので影響を受けない。

3)現在どのモード(Prev/Rend/VPR)に居るかを直接知る手段は用意されていない。
 Init()のmodeの様な物は無い。

※1:Nodeに対しては平時のタイムライン移動/RefreshによるNewtime()イベントが有る。
 が、非レンダリング時も発行されるので、毎回Newtime()で何かをすると平時の操作中も無駄に重くなる事に。


こんな感じ。

 VPRに対応しているという事は、それだけ冗長で無駄な処理を含んでいると言える気がする。
1)非効率なVPR版だけにして、本レンダリング時に時間の浪費を強いる。
2)VPR版と本レンダリング版の二つを作る。 設定詰めが終わったら差替える。
3)VPRは捨てる。
4)10.1以降でマシな改修がされる事を祈る。

4択かな。

処理内容の傾向/重さで適宜選択かねぇ。

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ
気持玉数 : 1
なるほど(納得、参考になった、ヘー)

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
ShaderClassとVPR もきもき3D/BIGLOBEウェブリブログ
文字サイズ:       閉じる