Programの最近のブログ記事

ランバートでシェーディングしたキューブ1個で4FPS程度か。ワイヤーフレームなら20から30FPS程度は出るが、ダブルバッファリングなんぞは無理なので、容赦なくちらつく。ワイヤーフレームは線引き関数で一発だが、ポリゴン面のラスタライズは自前でチマチマやるしか。

"あわよくば"、これでdemoでも作ってみるかなと、ここ数日書いてみて、プチコンでリアルタイムレンダリングさせてみたが、重すぎる。当初の目標ではper pixelシェーディングで色々やってみたかったが、これ以上重くなるとリアルタイムとは呼べなくなりそうだ。
DSiよりもパワーのある3DSだとより高速になっているのかと思ったが、そうでもなかったようで。多分同じ速さで動作しているのかね。リミッタ外せないのかな。

ハードウェアの支援など何一つ無い、低速なグラフィックへの読み書きなので、oldschoolな2Dのdemoも結構厳しいのではないだろうか。スプライトもサターン並みに変形出来れば、利用出来たのだろうけれど、このソフトはそういうコンセプトではない。

重い以外にも相当制約が厳しい。
数は固定小数点のみで、精度も余裕が無くカリングがうまくいかないケースがあるし、内積などで最大最小値を超えるとオーバーフローで止まる。
グラフィックは色が256色しか扱えないので、使う色を限定してさらに間引かないと多色を扱うことすら困難。
試しに深度マップ用意しようと愚直に256*192で配列を取ったら配列の限界数を超えるし、メモリも不足する。深度マップに関しては256色ながらも下画面のバッファを活用すれば裏技的に実現できそうだが、色の読み出しが大変重そうである。Zソートしか現実的ではないかな。

さらにBASICがクセモノというか、私はベーマガ世代でもなんでもないが、昔の人はよくこんな言語使って組んでたなと関心するほどに扱いにくい。非効率的すぎる言語だ。
スコープという概念というかローカル変数なんぞ無く、漢らしく全部がグローバル変数。サブルーチン先で値（特にFOR文のカウンタ）を上書きしてぶっ壊してえらいこっちゃ。
サブルーチンに渡せる引数も無いので、仕方がなく引数用の汎用的な変数を用意してそこに値をぶち込むのだが（これも変に値を上書きして壊さないように注意しながら）、行列1個で16回のコピーが発生するのがなかなか馬鹿にならないコストだと思うし、コピーする処理を毎回書くのが面倒である。

アドレスも扱えないし、個人的にはアセンブラの方がまだマシかね。

まあ、こんな馬鹿みたいなことをやろうとしなければ、良い言語だとは思わないけれど、良いソフトだと思う。タッチパネルの仕様の所為か、結構な頻度で押した場所と違う場所が押されてしまい、変な文字が入力されて嫌なことになるのが気になるけれど。

見れている時間よりもバッファが途切れてる時間の方が圧倒的に長い...最高潮の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前後の世代のビデオカードではパフォーマンスに天と地の差があるなあ。プロファイリングしてみたわけではないが、ピクセルシェーダの酷使に弱いのは当然だが、浮動小数点バッファの扱いが絶望的に遅いのか？やっぱり切り捨てたい。

今年はありますよ。応援。

2chparty 2009

今のところ日本唯一のonline partyなので盛り上がって欲しいし、盛り上げたいのだが、私めはdemo用に何か書いてたりするわけではないので、そちらに比重寄せて素人が今から作るとなるとどう考えても間に合わない。また来年。