見れている時間よりもバッファが途切れてる時間の方が圧倒的に長い...最高潮のPC Demoだし、負荷がかかると遠くの国は繋がりにくいのか？アメリカ経由はしていないみたいだが。
昨日のStreaming Music前あたりまでは普通に見れていたんだけどなあ。最後なのに残念。
初めて意識してDemoを見たのがfr-08: .the .productだからもう10年か。
プログラムの最近のブログ記事
VSM結構使いにくいなー。NVIDIAのGDC08資料とかGPU Gems 3に大体書いてることです。
Light Bleedingはいくつかの回避策があるのでなんとかなるのだが。
まず、レシーバのみのモデルもシャドウマップに描画しないと駄目だ。でないと分散値はぼかす際に近傍付近のピクセルが混じり合うので、本来得たい分散値とは異なる値になってしまい、影のdetailが不自然になってしまう。
で、VSM下ではレシーバのみのモデルは存在できなくなり、これもキャスタ扱いになる。本来レシーバのみで十分なモデル（ゲームでは地面がよくあるケースだろう）の形状によってはどうしても通常のシャドウマップよりも広範囲を描画しないと駄目になるので、最適なクリッピングが出来ずに解像度が稼げないということに陥る可能性がある。レシーバとキャスタの描画範囲の差が大きくないシーン（キャスタが広範囲に分散しているとか）は、VSM以外でも大変なのでクオリティに差は出にくいだろう。
減衰があって範囲が絞れるポイントライト系で使用するのが無難なのかな。カスケードで近距離のみVSMで後は別の手法というのもありだろう。
それから、当たり前だがハードウェアシャドウマップが使えないのでパフォーマンス面でも結構不利だ。NVIDIAのSIGGRAPH07資料やGPU Gems 3などで、フィルタサイズでのパフォーマンスはPCFより圧倒的に有利じゃないか的なグラフが出てたりするけど、ハードウェアシャドウマップが使えなかったり、精度的に浮動小数点バッファ推奨だったりすることを考慮すると、必ずしもPCFより高速とは言い難いんじゃないかと思う。ハードウェアシャドウマップはそれはそれでハード依存のコードが出るし、資料漁りも面倒なんだが。
GTX285にしてから FEARとかHitman Blood Moneyで STOP 0x000000EA THREAD_STUCK_IN_DEVICE_DRIVER (Q293078) が出てOSごと応答不能になるなあ。最新も込みでいくつかドライバのバージョンも変更してみたのだが駄目だ。
どちらのタイトルも発売年的に結構近い。NVIDIAとATIがShaderModel2.x系でユーザのことも考えずに仕様を拡張しまくって凌ぎを削ってた頃に開発されていたと思われるゲームなので、その影響をうけてるんじゃないのかなと予想してみるのだが、普通に重めのコード実行させていてもクラッシュしたり。単にドライバの出来が悪いだけか。
VSM作ってみたけど、Light Bleedingが思ったよりも出まくるのでLight Bleeding対策は必須だなこりゃ。NVIDIAのサンプルではLight Bleedingが出にくいモデルだったり配置だったりするのだが、ゲームで使用するとなるとそうは言ってられないのでまず頻出する問題だろう。
テクセル誤差のアーティファクトは大体消えるのだが、それでも分散の誤差のようなノイズがマシンによって出たり出なかったり。下手にbias入れると半影部分でもbias入れた影響が出て微妙に。
あとは平行光源でも使えないこともないけど、点光源での使用を想定されているので、距離の算出方法を変えないと分散量が点光源のそれになってそうで、位置関係によっては点光源のような半影になっちゃいそうな気が。実際に比較するときの距離もシャドウマッピングの時と同じ位置からの算出だから大丈夫だったり？
VSMに限ったことではないが、unified前後の世代のビデオカードではパフォーマンスに天と地の差があるなあ。プロファイリングしてみたわけではないが、ピクセルシェーダの酷使に弱いのは当然だが、浮動小数点バッファの扱いが絶望的に遅いのか？やっぱり切り捨てたい。
今年はありますよ。応援。
今のところ日本唯一のonline partyなので盛り上がって欲しいし、盛り上げたいのだが、私めはdemo用に何か書いてたりするわけではないので、そちらに比重寄せて素人が今から作るとなるとどう考えても間に合わない。また来年。
Inferred LightingとはSIGGRAPH2009で出たやつ。念のため下記の内容は個人的要約に基づくものであって正当性は保証しません。あしからず。
名前の通りDeferred Shadingの亜種というか、Light Pre-Pass Rendering(Deferred Lightingとも)の発展系にあたるのかな。基本的になパスはLight Pre-Passと同じ。
Light Pre-PassではDeferred Shadingでのメモリ帯域へのコストを減らせる代わりに1パス追加されました。この追加パス分のコストを取り戻したいのでInferred LightingではDSFバッファなるものをGバッファ描き出し時に追加で描き出しておいて仕込んでおく。DSFバッファの内約は線形深度とオブジェクトIDとグループID。このあたりの発想はSTALKERのGバッファ構成が元ですね。
で、Lightingパスで縮小レンダリングを行ってパフォーマンスを稼ぐわけですが、普通に縮小レンダリングしたものをアップスケーリングして、Albedoやらの要素を等倍でレンダリングしたテクスチャと合成すると、当然エッジ付近でピクセルの不一致が発生してチラチラとアーティファクトが出てしまう。特にMSAAを使うとこのエラーは酷くなる。これをDSFバッファとCentroid（これは遅延レンダリング系特有の手法ではないが）で解決していくのがミソらしい。
さらにアルファのポリゴンもこのレンダリングラインに乗せれるらしいのだが、どうやるかというとアルファポリゴンはライティング時に2x2ピクセルをインターバルに点を打つらしい。で、アップスケーリング時のバイリニアフィルタでうまく混ざるらしい。2x2ピクセルだと4レイヤーまで、4x4ピクセルだと16レイヤーまでアルファを解決できるが、当然解像度は低下していく。
さて個人的にはちょっと使えないかなとは思う。
まず、ライティング部分だけとはいえ縮小してるので当然精度は荒くなる。特に法線マッピングでのディティールは著しく潰れるだろう。まあ、コンシューマ機だと性能が足りなくて、レンダリング解像度は大抵縮小されてるゲームが多いので他と比較しても遜色は無さそうだし、むしろマテリアルパスでのAlbedoなんかの解像度は等倍なので見栄えは良いかもしれない。この辺はクオリティとトレードオフなのでLight Pre-Passのパフォーマンス向上を狙って取り入れる分にはありか。
アルファは確かに使えるとは言っても、透明度25%の倍数で4レイヤーまでなので、実際にはどうしようもなく使えないだろう。ムービー見ると透明度が変化してるようにも見える気がするけど、自力でサンプリングしてブレンド係数変えると実現できるのかな？一応Albedoでの透明度はそのままなのでちょっと妙だと感じる程度にまで抑えれる気がするけど、これだったら別ラインにはなるが普通にForward Renderingでやった方がフレキシブルで良さそう。16レイヤーになっても、ライティングの解像度が余計に酷くなるし透明度が倍数固定な以上、半透明が出てくる頻度にもよるが実用的ではないと思う。
余談。SIGGRAPH2009とLight Pre-Passつながりしかないけど、CryEngine 3のリアルタイムGIの手法も発表されて当然見てみました。アホの私には詳細な実装の仕方が頭に描けず、概要を把握するだけで一杯一杯でしたが、重そうなのによく3～5msまでに抑えれてるなあと。Volume Textureの解像度は相当低くて十分っぽいので（32^3）、これで計算回数が激減されてるのかな。
前回のを踏まえて、もうちょっとデバイスの初期化と取得できるデータの蓄積なんかを今よりもちゃんとしとかないとまずいよなということで、ゴリゴリその辺を書いてるんだがめんどくさいな。
データ取ってくるだけの処理なので誰が書いても似たような感じになるはずなのだが、その辺のサンプルレベルでやるには大袈裟な物量なので誰も公開してないが、ユーザに使って貰うには必須というのが面倒この上ない。
SDKのDirectX Caps Viewerのソースがあればリファレンス見返す頻度も減って参考になるんだろうが、こういうのに限ってソースが含まれてないしね。
で、いつものことだがそのリファレンスもリファレンスらしからぬ書き方をしてたりして萎える。D3DRTYPE_SURFACEの説明が「サーフェイス リソース。」とかね。そんな説明は定義された文字列を見りゃ誰でも分かるわけで、良くないコメントの書き方の典型すぎる。
DX10からはこの作業は無くなるわけだが、DX10とVistaなんて誰も使ってないし将来もないし、DX11はやっとプレビュー段階で対応ハードすらまだないのでどうにもならん。DX11は主流になってくれるのかは分からんが、とりあえず未だに固定機能頼りの多い個人規模だと敷居は高くなりそうだ。VSとPSはSM3.0未対応のハードを切り捨てる勢いで使ってるので主流になりそうならDX11に移ってもいいのだが、GSやらCSの使い道は未だによく分からん。
CSのテッセレーションはストリームの量減らせるとかLODが楽とからしいが、普通にハイポリモデル用意する方がアーティストにとっては楽だし意図した結果にコントロールしやすいんじゃないかと思う。パフォーマンスが犠牲になってもね。他にも色々使い道がありそうなのはいいが、普通の人が扱いこなせる範疇なんですかねえ。
GSに至っては結構出てから経過してるのに、頑張ってるなと思ったのはNVIDIAのヘアシミュくらいだしなあ。酷いはポストエフェクト用の矩形ポリ作ってるだけとか。
Larrabeeなんて固定機能とは真逆を行ってるわけで、余程下地が整っていない限りレンダラ方面の人だけが弄るだけで終わりそうな気がするんだがはてさて。
色々と機能追加しつつ高速化しつつリファクタリングしてみたので、久しぶりにノートの方で動作確認してみようとしたら見事にブルースクリーン。
以前はMSAAを使うと青画面になってたので今回は最初から切ってたのだが、それでも駄目らしい。恐らく浮動小数点テクスチャの一部のフォーマットが対応してないだろうということで、R16FとかG16R16Fとかの拡張されたやつを無難なARGB16Fに変えてみたのだが変化無し。これで前は動いてた気がするんだが。
ノートのグラフィックチップはMobile Intel 965 ExpressはShaderModel 3.0になんとか対応してるようで、最低限のスペック上での動作確認にはなかなか便利。一応最下限のターゲットにしてみようかと思っていたのだが、真面目なエラーチェックとオプションでのオン/オフを入れないと動いてくれなくなってしまったようだ。もっとも動いてくれたところでリアルタイムとは言い難い速度で動くんだろうけど。
こいつよりもデリケートな印象のあるATI系は手元に無いのでさらに心配だ。真面目にやるなら検証用のマシンも作らないとなあ。
今のところGF8x系以降が推奨レベルで、テクスチャフォーマットの対応さえとればGF7x系が速度はともかく動作可能レベルなのかなあ。ひでぇ。ShaderModel 2.xとかはバージョンが乱立しすぎてしがらみがややこしいので全部切り捨てる方向で。
きっちり対応できてるPCゲームは偉大だわ。
今更Tone Mapping作ってみたんだが、これはどうやって正しく処理が行われていることを確認すればいいんですかね。
YCrCb系だと色相が明らかに変になったので、Reinhardと同じようにXYZ系にしてみたのだがなんか合ってるような気がしない。背景のカラーをサンプリングして比較してみても色相は狂ってなくて、明度と彩度は変化してるのだが、モデルなんかはコントラスト比が変わりすぎて違和感を感じる。
そもそもLwhiteが1.0の時は0から1の線形になるはずなのだが、そうではなくて補正がかかっちゃってる時点で計算に使う値がまちがっとるんだろうか。Reinhardのソースをもっと見ろという話ではあるのだが、ごにょごにょ。Reinhardの手法を使ったと思われる他の人様のソースも見事に計算式に使う値がバラバラだったりするのは何故なんでしょう。
Reinhard以外の手法で感光シミュあたりの方が良好な結果が得られるんだろうけど、Reinhardの手法の場合は先述のようにLwhiteによって補正カーブの形状が変化してくれるはずなのがおいしいなあと思う。特に1付近の低い値のケース。補正されすぎないようにLwhiteを適度にクリッピングしておけば一番扱いやすいんじゃないか？
扱いやすいといってもアーティストの間ではトーンを自分でコントロールできないTone Mappingは不評なわけですが、個人でやる限りには自動でやってくれる方が用意するデータとパラメータが少なくてもそれなりの見栄えになるので多分楽だろう。
TGC2009でのプレゼンで用いられたCryEngine 3に関する資料が公開されてました。
読んでて疑問符が浮かんだ某所のは間違いだらけじゃないか。今に始まった事じゃないけど。ついでに、このblogも正確性なんてものはあてにしないで下さい。
Deferred LightingはForward Shadingと、Deferred Shadingの合いの子みたいな感じで以下のようなパス。
- Deferred Shadingと同じようにライティングはしないでG-Bufferをレンダリングする。ただし基本的には、Z値と法線とスペキュラパワーのみ。
- 1で描き出したバッファを元にライティングのみを行う。一般的なのはDiffuseとSpecularのみで、各成分を分けて描き出すかはその後の用途次第か。今回の資料ではIBLと同じだとは言ってるが、確かに似たような感じだがDeferred Shadingにも同じことが言えるので言いすぎな様な気もする。ともかくDeferred Shadingと同じような恩恵は受けれる。
- Forward Shadingと2のバッファを使って描き出す。深度テストもシェーダでやるなら1も必要か。Deferred Shadingとはここが違う箇所。Deferred Shadingでは使うが1で描き出してないバッファは不要になるし、Deferredであんまりやりたくないようなこと（多分専用のシェーディングとか？）はここで出来るし、半透明も完全別扱いのような扱いはうけなさそう。
加えて、ポストエフェクトは2の後でも3の後でもできるのでさらに柔軟になってると思う。
つまり、Deferred Lightingは2回のジオメトリ処理が必要になってしまうというデメリットはあるが、Deferred Shadingでのボトルネックになりがちなメモリ帯域不足を、分けて描き出すことでその辺の負担を減らせているというのが特徴になるのか。そりゃ帯域とメモリが無尽蔵にあるのならDeferred Shading様々なんだろうけど、そうではない今の時代（特にPS3とXBOX360）に即したシェーディング方法と言えそうだ。
と、ここで気になるのは影の扱いだ。別の資料にはステンシル使うとか書いてたりもしたが、今時そりゃねえだろと言いたいが（FEAR2のキャラクタの影はステンシルシャドウだったが）、いつも通りにシャドウマップ作ってるとジオメトリ処理が3回になってしまい結構大変なことになるので、なんとかしたいところだ。
Resistance 2の資料見た感じでは詳細はよく分からなかったし、CryEngine 3も同じやり方かどうかも分からないが、描き出してきたバッファを利用してなんとか処理できないのかなあ。Interleaved Shadowmap lookupsというのが何を意味してるのかはよく分からんのだが、追加のメモリがいらずに帯域も少なめでOKで、マスク数制限も無いということはシャドウマップの描き出しをして無さそうだが、Shadowmapって言ってるしなあ。想像に過ぎないが、スクリーンスペースで諸々のバッファと光源位置を元に読み取り先のUV値を決定して、それらのZ値との比較から影かどうか判断するみたいなこととかできないのかな。
その他、細かいCryEngine 3の特徴メモ。
- スペキュラの格納をRGBか単色か選べる。
- 法線圧縮。定番だが、座標系による精度も気にしてるっぽい？
- キューブマップ作ってIBLもできるっぽい。Deferred Lighting時に適用するんだろう。
- SSAO。海外では定番になりつつある気が。
- 動的GI。相性の良さそうなSSDOな気はするのだが、SIG09で発表するらしいので別の手法なのかもしれない。
腐ってやがる...
早すぎたんだ
