トップ 最新

kumaryu日記

2010-12-15

_ 日記

rubyがまだ落ちた。

libstdc++を明示的にリンクしてたのをそのままにしたらむしろ駄目だったので-lstdc++は外しておくことに。 これでちゃんと終了時に落ちなくなったので安心。

やっと新マシンで作業の続きができるよ。と思ったら作業中でコミットしてなかった分を移行してないな。コミットせずに結構作業してたのか。いや、コミットはしたけど同期してなかっただけだった。分散バージョン管理の弊害がこんなところに!

ネット接続した瞬間にリポジトリの同期をはじめちゃえばいいんだな。しかしネット繋がった検出ってどうやるんだろうな。めんどくさそう。

_ [Riko] 本当にシェーダを書かないと

今まで描画システムは柔軟にしたいなーとか考えてたんだけど、せっかくRubyで書いてんだからシンプルでいじりやすくさえ書いておけば柔軟であろうことに今更気付いた。

そこまで出来たらさすがにそろそろシェーダを書かないといけなくなってきた。 いろいろ書くのもいいが、どうせ使わないものを書いても途中で飽きるだけなので何を使いそうか考えよう。

  • Constant
  • Lambert
  • Phong

このくらいはまあ必要ですよね。つかとりあえず必要なのはこんなもんであとはこの派生だわね。

  • 照明処理
    • 頂点単位
    • フラグメント単位
      • 法線マップ
      • 影マップ
  • 環境マップ
  • 環境遮蔽マップ
  • 動的環境遮蔽

環境マップはともかく他はちょっと贅沢だな。静的な環境遮蔽マップなんかはデータさえ作れば貼るだけなので簡単だけどそんなに要るかっつーと後でもいいかも。背景とかだったらむしろライトマップにして照明焼き込みたい。法線マップは難しくはないので頑張ってもいいしあるとそれなりに素敵。

動的な環境遮蔽はやるなら画面空間でなので、モデル描画する時には必要な情報だけ書き出しておけばいい。書き出すのは大変じゃねーけどすぐやるべきことじゃないし後まわしだな。

シャドウマップはやりたいけどなー。これが一番めんどい。何がめんどいって1パスで描けないのがなー。

いやいや悩んでても仕方ないんで当面やることを決めよう。シャドウマップはひとまず後回しだ。シャドウマップさえ描ければ普通の描画にぶちこむのは簡単だし。

ということで必要なのは、

  • Constant
    • 照明
      • 頂点単位(っつーか照明処理しないし…)
    • 環境マップ
      • 有り(?)
      • 無し
  • Lambert
    • 照明
      • 頂点単位
      • フラグメント単位
    • 環境マップ
      • 有り
      • 無し
  • Phong
    • 照明
      • 頂点単位
      • フラグメント単位
    • スペキュラーマップ
      • 有り
      • 無し
    • 環境マップ
      • 有り
      • 無し

こんなもんかなー?法線マップはどこいった感があるが、それはまた今度。一歩ずつ書いてくよ。

これだけでも結構な数になっちまう。えーと…14パターンか。

光源は今のところ平行光源3本に点光源2つくらいをシェーダで処理しようかなぁと。平行光源もう一本くらいあってもいいかな、点光源もう一個くらいあってもいいかなとか思わんでもないがまあいいや。パラメータ結構多いんで。

平行光源3本はまあだいたいいつも必要だろうからこれは固定で入れてしまおう。Constantにはもちろんいらないが。

点光源は悩みどころ。使ってない時には処理を外したい。しかし動的に増減させるならその分シェーダを分けないといけない。めんどいね。

点光源0~2つで分岐させるなら3倍か。Constantはいらないから40個。

ディフューズマップの有り無しもあってもいいかなーと思ったけどテクスチャ貼らないのは無視してもいいかな。やるならConstantだけ。

UVスクロールが欲しいんだけどこれはどうやればいいのかわからん。テクスチャ座標に変換行列かけてあげればいいのかな?UVスクロールするならテクスチャ重ねられた方がいいかとも思うけど今はいらんか。テクスチャ座標変換の有無で倍。80個。

ある程度は手で書いてマクロとかで展開させるから80個書くわけではない。書く必要があるのは…頂点単位照明とフラグメント単位照明をLambertとPhongそれぞれに書くくらいじゃね?あれ、LambertってPhongのスペキュラ無い版だっけか。ConstantってLambertのディフーズもアンビエントもない版だっけか。1つの超シェーダだけで十分ですよ。Uberってほどでもないか。

書くのは少なくても実行時に80個コンパイルして保持してないといけないね。コンパイル後のサイズはよくわからんけどプログラムのサイズなんかたかが知れてるので80個程度ではサイズは気にしなくてよさそうだ。テクスチャ1枚のほうが余程でかいだろう。コンパイル時間が大丈夫かなーとは思うものの、そんなに遅いわけもないからまあ80個ならたぶん1、2秒もあれば終わるんじゃね?終わるといいね。もちろんCPUパワーに依存してしまうわけだが、80個程度ならきっとモデル読み込む方が遅いんじゃないだろうか。

そういや今考えてるターゲットは、練り歩きゲーを作りたいなーと思ってて、描画が3Dなのでしゃどう☆こんぷれっくす的な感じになると思う。なのでキャラとかは小さめの表示になるんであんまり豪華にしても無駄だろう。背景なんかが(楽に)綺麗になる方に気を使いたいね。