PBR->C++ コードジェネレータ

これ本当に有用なのか疑問に思えてきた。

速度的なアドバンテージは大きいか？

当時はシェーダ内で仮想関数コールなんてしてたら遅くて使い物にならないだろうと思ってC++コードジェネレータに走ったのだろうけれども、実際nytrはもっとinner-loopのレンダリングアルゴリズム本体の方で仮想関数コールを多用している。*1

実際filterを実装してみたところ、ObjIDレンダリング有りの場合と無しの場合、レンダリング時間の差異は誤差の範囲内であった。そもそも、よっぽど軽いシェーダでもない限り、仮想関数コールの影響は見えない。テクスチャ参照が一回入るだけでも膨大なメモリ参照が生じる。

コンパイルが大変

C++コンパイラが常に用意されてないといけない。下手すると↑の速度的アドバンテージもコンパイル時間でなくなってしまう。

どうする？

ShaderBlockのモジュールだけC++で作っておいて（これは今まで通り）、構文木というかシェーダツリーをPBSファイルから動的に作成＆レンダリング？（以前の予定ではHard-coded C++)
結局C++コード生成→リンクだった構文木解釈を動的にしただけ？

多チャンネル出力用に作ったSampleValがうまい具合で使えそう。実装はreinterpret_castしまくりだが、オーバーヘッドはその出力が必要かどうかの分岐一回。（単出力のShaderBlockでは省略可）

もうちょっと考える。

追記：

本当に木構造（枝同士がつながるのは無し）をとっていないとパースできないな。同じテクスチャ・同じ座標への参照があった場合2回参照することになってしまう。これはまずい。

ただキャッシュすればいいだけの話。

*1:PhotonMapやIrradianceCacheをDecoratorパターンで実装している