さて、今回は個人参加のため会社にレポート提出の義務はありません。
というわけで忘れないようにこちらに書いておきます。
まず基調講演はコーエー社長の松原さんが自身のキャリアをちょっと話した後にCEDECの今までとこれからについて話をされました。
今後もCEDECは重要になるでしょうし、個人的にも頑張ってほしいところです。
次。1コマ目。というか、今回はImagireDayのみ行ってますので、ImagireDayの1コマ目です。
シリコンスタジオの川瀬さんと田村さんの講演でした。最初が田村さんの影に関する技術の話、次が川瀬さんのポストエフェクトの話です。
田村さんの講演は『Real-Time All-Frequency Shadow in Dynamic Scene』というSIGGRAPH08の論文の話でした。
これは環境マッピングを光源として動的シーンに影を落とす手法の1つです。
SHEXPを使用した同種の技法については以前田村さんが講演してましたが、この技術は影がソフトすぎてハードな影は出せません。
今回の方法はソフトな影もハードな影もOKな代物のようです。
理屈はけっこう簡単で、キューブ環境マップの各面において光源を複数の面光源に変換し、それらすべての面光源についてシャドウマップを行うという手法です。
まず、キューブ環境マップの各面において、最も明るい点をピックアップします。
これをある数式が満たされている限り近傍に矩形を広げてゆき、広げられなくなるまで広げたらそれを1つの面光源とします。
残りのピクセルについても同様に行ってゆき、最終的に面すべてについて検証したところで終了です。
これら面光源について影を落とす場合、”Convolution Shadow Map (CSM)”という技法を使います。
このCSMを説明する前に”Percent Closer Filter (PCF)”というソフトシャドウ生成技術について説明が行われました。
これは知ってる人も多いと思いますが、あるピクセルでの影判定を行う場合、その近傍のピクセルとの判定も行って影となる割合を求め、これを影の濃さとする手法です。
つまり、PCF はデプステスト→フィルタと処理するのですが、これをフィルタ→デプステストとするのが CSM です。
そういえば、以前やった VSM もフィルタ→デプステストですね。
これについては元の論文を読んだほうがいいかもしれません。数式もスライドで示されたのですが、座った位置が遠すぎて見えませんでした。
いや、わざとそんなところに座ったわけじゃありません。人が多くてその辺しか空いてなかっただけです。
また、CSMではフィルタのサイズを固定するのですが、今回紹介された方法ではフィルタサイズをピクセルごとに変化させるようです。
この辺の計算式も見えませんでした。後で論文で確認しましょう。
でまあ、この方法で面光源に対して影をつけてくわけですが、この辺の説明があんまりなくて詳しい実装法がよくわかりませんでした。やっぱり論文を読もう。
まとめとしては、力業だけどできる、でも重い。1つか2つならいいかもしれないけどそれ以上だときびしくね？ってことのようです。
次の川瀬さんの講演は去年もやったポストエフェクトで現実的に正しい（ものに近い）ボケの表現手法について。
まずはレンズの話ですが、これは去年もやったのかもしれません。私は聞いてないのでわかりませんが。
レンズは平行光源がまっすぐに入射した場合ある焦点を結びますが、点光源がレンズの真正面にあった場合、点光源が近づくほど焦点は遠くなります。
これがピンボケを作る理屈です。他にも色の波長によっても焦点位置が変わりますし、斜めに入射する光に対しても焦点距離がずれます。
例えばレンズが円形であり、収差がない場合、レンズの距離と焦点からのずれはボウリングのストライクのマークみたいになります。一番狭まっている部分がピントの合っている場所になります。
X軸をレンズからの距離（0.0?1.0）、Y軸をボケとして表現した2次元テクスチャが上記のようなマークに似た図になりますが、これをテクスチャとしてピンボケを表現できますよ、という話でした。
アニメなんかだと夜の街を表現する際に、ネオンの光が強いところに半透明の円を置いてみたりしてボケてるように見せかけることがありますが、これをポストエフェクトとして使おうというわけです。
さすがにすべてのピクセルに対してスプライトを置くわけにはいきませんが、それっぽくボカしたい一部のピクセルだけにこの対処を行うのであれば負荷はそれほど高くなりません。
テクスチャは事前生成できますし、複雑な収差を考慮にいれたボケも表現は十分可能です。
ただ、実際のカメラのボケはそんな正確で綺麗な形状にはならないため、その辺も考慮しないと不自然になるかもしれません。
個人的には、そこまでやらなくても大半のユーザはわからないんじゃないかと思ったりしますがね。
2コマ目はトライエースの五反田社長によるシェーダ管理の話でした。
これの資料はそのうち research.tri-ace.com の方で公開されるものと思われます。
ゲームのプロジェクト内でシェーダを作成する場合、いくつかの方法があります。
まず、大きなシェーダプログラムを書いて、そのプログラム内で分岐とかを利用する方法です。
基本的にシェーダプログラムは1つになるので管理は簡単ですが、シェーダ内の分岐というけっこう負荷の高いことをするためパフォーマンスは落ちます。
プリプロセッサを用いる方法もあると思います。分岐を行うよりこの方向を考えたほうがいいかもしれません。
次に1つ1つのシェーダを手で書く手法ですが、パフォーマンスチューニングはもっともやりやすいと思いますが、バリエーションが増えれば管理は非常に難しくなります。
3つ目はオフラインでシェーダを自動生成する方法です。プログラマの手を介さずにデザイナがシェーダをいじれますが、やはり管理が厳しくなります。
トライエースでは4つ目の方法である、ランタイムでの自動生成を行っています。この方法はバリエーションを簡単に作成できる反面、バリエーション爆発が起こりやすくなります。
シェーダはMAYA上で設定できるように独自のシェーダノードを作成しているようです。そのため、シェーダをかなり細分化しているそうです。
シェーダノードは1つ以上のシェーダキーを生成します。シェーダキーはヘッダと複数のチャンクから成っていて、関数の引数や出力変数などを指定します。
また、視線ベクトルや反射ベクトルは使用する・しないに限らず計算します。使用しなければコンパイラが最適化してくれるからです。
他にもシェーダ内で使用される定数をシェーダごとに設定できるようにしたりしているようです。
さて、当初シェーダ用のキャッシュメモリは20MBと設定しておいたらしいのですが、気付いたら50MBを超えていたそうです。
これではでかすぎるので色々やってみたけど、ほとんど減らない。というか、減ってもいつの間にかシェーダが増えてる。
それもそのはず、あるゲーム（ぶっちゃけインアン）では、5月の段階で34000個のシェーダが存在していたそうです。最終的にはもう少し増えてたかもね。
なぜそんなことになるのかというと、1つは同じマテリアルであってもライトの数などで処理が変わってくるからです。
シェーダでは if や for はコストが高くなります。ライトの数が n 個までだからといって n 回のライティング処理を行うわけにはいきません。
n 個が最大なら、0?n 個でそれぞれ別のシェーダを作成しないといけないわけです。
ほかにも、定数がちょっと違うとか落とされる影の数が違うとか、影処理方法に違いがあるとかでそんな数になってしまったようです。
別のプロジェクト（多分SO4）ではエリア1つで2万個以上のシェーダを使っているようです。ちなみに、インアンのエリアは1つで1万個くらい。
この辺をどう解決したかはメモを取れなかったので、資料配布されたら読んでみましょう。
まあ、なんというか、トライエースでもこんなに苦労してるのか、と思うとちょっと滅入ってきますね。
しかし、例えばいくつかの技術についてはシェーダパスを統一するなどである程度の対処は出来ると思います。
そのためにはデザイナを統括するような人物は必要になるのではないかと思います。難しいことかもしれませんがね。
3コマ目はフロムソフトの三宅さんの話。プロシージャル関係ですが、AIセミナーとかで話してる内容がほとんど。
新規の話題はSPOREくらいかな。何度か聞いてる話なので、ここで書く必要もなさそうです。
ただ、シューティングにプロシージャル技術を利用するのはシューティング復活の1つの方法ではないかという話は半分納得できます。
スクロール系のシューティングは地形の変化、敵の出現などが洗練された演出として存在しています。
それこそ演出を自動生成できなければ面白くないゲームにしかならないのではないかと思っています。
ですが、1画面ゲームはプロシージャル技術と相性がいいかもしれません。ランダムで出現するより予測できないけど何らかの法則性があるように見えたほうが面白くなるかもしれません。
また、ギャラガレギオンズやスペースインベーダーエクストリームはステージ分けされていない無限モードがありません。
もし、プロシージャルにギャラガやインベーダーの隊列をいい具合に生成できるのであれば、より面白いゲームに為るんじゃないかと思います。
しかし残念ながら、三宅さんの作ってきたプロシージャル生成している3Dシューティングは面白そうには見えなかったですね。
最後はバイナムのImagireさんによるプロシージャルグラフィック関係の講演でした。
まず、シェーダに必要なデータの中には自動生成できるものはけっこうあります。
様々なテクスチャはまさにそれで、デカールマップだけでなく、位置マップ、法線マップ、アンビエントオクルージョンマップなんかが自動生成可能です。
また、面白い方法として逆アンビエントオクルージョンなんかも作れます。オブジェクトのエッジや曲率を調べるのに最適かもしれません。
これらを利用して作成されたのが、傷やほこりの積もりなどによる経年劣化。
シェーダパスについてはメモを取れなかったので資料が上がったらチェックする方向で。
サンプルの映像ですが、パッと見、経年劣化っぽくは見えなかったです。全体的に色をくすませてみるとか、ほこりにノイズを使ってみるとかすればもう少しよくなるような気もします。
まあ、その辺はデザイナが協力すればきっといいものが出来るでしょうし、モデル作成（UVマッピング含む）とシェーダ作成以外のリソースは自動作成できるわけで、これが非常に重要かと思います。
インベントリ内のアイテムが経年劣化していくのがわかる、とかってなるとゲームの見た目もかなり良くなるんではないでしょうか。
次に紹介されたのが移流テクスチャ。ノイズを流して流体っぽく見せる手法です。
たしかSIGGRAPH08での論文が簡単に紹介されていました。これはフラクタルノイズを組み合わせる手法らしいのですが、実際に紹介されたのはそれより簡単な手法です。
UV座標をブロックごとに違う方向に流してノイズを描画することで、それっぽく動く雲とかを実現することが出来ます。
しかし、ただUV座標を流しただけではある場所で停滞してしまうこともあるでしょう。
これを防ぐために適当なフレームでリセットすべきなのですが、いきなりリセットするとリセットしたのがばれてしまいます。
そこで、いくつかの時間をずらして流しているテクスチャを合成することで解決できます。
サンプルでは3枚でやってましたが、その合成の重みは複素平面でぐるぐる回る水車のようなベクトル群の実部を用います。3枚ならベクトルは3本。
後はひずみテンソルとか何とか…この辺はよくわからなかったです。すまぬ。
ノイズが動くと楽しいかもね、という技術でした。
最後にL-Systemを用いた樹木生成の解説が行われました。これは急遽付け加えたものらしく、1日で作ったらしい。すげぇ。
まず、1本の木の枝をモデリング。これを縮小・ひねりを加えてそのモデルにアタッチします。
縮小具合やひねり具合、アタッチする位置や方向などがプロシージャルに計算されます。
これを何度も再起していくと樹木っぽいものが作成できます。実際、それっぽくなってました（ちょっと横に長いけど、L-Systemの樹木サンプルってたいてい横に長いように見えますね）。
問題は再起の回数で、回数が多くなればなるほどしゃれにならないくらい重くなります。
そこで、ある程度の回数以降は通常の方法で作成したものをビルボードのテクスチャとして貼り付けるという手法を用いました。
ボリュームテクスチャも使ってけっこう楽しそうな手法でしたが、やはりビルボード部分がくるくる回ってしまって、角度次第ではおかしな具合になってしまっていたのが残念でした。
とはいえ、ビルボードを使っている以上避けられないしなぁ…。
でも、使い方を研究すればLODに使えそうな技術ではあります。海外では当たり前のようにやってるのかもしれませんがね。
今回のCEDECはスライド資料を紙で配布していなかったため、後ろのほうに座るとかなりきついですね。
スライドにない内容を出来るだけメモにとって、あとで公開される（はずの）資料と付き合わせる必要がありそうです。
あと、人多すぎ。一部に人気集中しすぎ。仕方ないことではありますが。
