シェーダ管理を行ったときのメモ

日記 開発


ようやっとプロジェクトが一段落してきたので、ここまでに得た事を機密情報を避けながらメモをまとめておく.
今回のプロジェクトは、はじめてプログラマブルシェーダの実運用を行った.
サンプル書いてみたりして遊んでいたけれども、やはり実践編は得るモノが多いなと感じた.
メモとして書き出してみると、(改めて)当たり前の事が多いことに気がつくのだけれども…

ま、とてもよい勉強になりました.


そんなわけで以下メモの展開

わかったこと

  • 動的分岐は処理速度的に損
  • フラグメントライティングを利用すれば、頂点数/ポリゴン数が少なくても見栄えは落ちない
  • 描画前に決定できるような分岐処理は動的分岐を利用せず、分割したシェーダを用いた方が良い
  • (環境依存だと思うが)定数の条件文はシェーダのコンパイル時に最適化される可能性が高い
  • シェーダ内で1.0fと書かない(ドライバによっては実行出来るが、リテラルを用いずに1.0と書く必要がある)
  • 動的分岐を嫌って静的に分割したシェーダを用いるとシェーダの数が一気に膨れあがる

なんとなくわかったこと

  • 頂点フォーマットのサイズは処理速度に影響する
  • varying 変数の数が増えると処理速度的に損
  • 処理速度が、フラグメントシェーダのネックになっているか、頂点シェーダのネックになっているのか把握が難しい

→ まず、必要なのは描画のパイプラインの理解は必須知識
→ 例?:(VS(...→ 視野座標変換 → 射影変換 →...) → 画面クリップ → DepthTest → FS(...→ AlphaTest))

  • Uniform の設定(glUniform*)は意外に遅いらしい
  • varying変数/uniform変数/attribute変数は、命名規則を明確に決めてしまった方が良い.

ライティング

  • フラグメントライティングの見栄えは非常によい
  • (ライトや視線の)ベクトルは、オブジェクトのローカル座標に変換して利用した方が得
  • バンプマップは(処理速度的に)遅い手法ではない

バンプマップ

  • バンプマップと言っても、手法は複数存在するので、トレードオフを判断する必要がある
  • 法線マップの座標系は取り扱いに注意する必要がある
  • 頂点座標系変換済みバンプマップは、フラグメントライトとほぼ等価の速度が出る(はず)
  • 頂点座標系変換済みバンプマップには、頂点法線ベクトルも接ベクトルも必要無い
  • テクスチャの解像度によっては、ざらざらした感じが出てしまう
  • 頂点座標系変換済み法線マップは、頂点ブレンド(スキニング？)が行えない

UVアニメーション

  • Image の座標系がどのようになっているのか把握することは重要
  • オーサリングツール上でイメージが左上(0,0)の場合、OpenGLでは左下(0,0)なのでUVの入れ替えが必要
  • いわば、右手系と左手系の様な関係にある
  • UV座標を単純出力する場合には、Y軸(V)を反転する(1.0 - V)と変換済みのUV座標が手に入る
  • しかし、アニメーションのデータを出力する際には注意が必要.
  • scaleが掛かったときには、translateにも考慮する必要がある
  • UVアニメーションの適用時には、TextureのRepeatmode への考慮が必要になる.

例: Imageの座標系をあわせるためにVの反転を行う場合、(V * -1)としてしまうと、Repeat以外では異なる表示になる

擬似コードとして次のような対応を行った

scaling_trans = 1.0f - scale;
trans = trans + scaling_trans
transformation( trans, rotation, scale )

なんとなく考えたこと

  • cgfx(Cg)やtechnique(HLSL)のpassは結局使い物にならないのでは？
  • フラグメント処理がネックになる場合、早期Zテストは有効な手法かもしれない
  • スペキュラだけ別バッファにレンダリングして後で合成すれば良い？
  • model単体での描画は不便だ