
|
|
What is mshdribl ? |
mshdribl は、DX9 以降の期待のフィーチャーでもある HDR (High-Dynamic Range : ハイダイナミックレンジ) な輝度情報を持つレンダリングを、 DX8 (正確には頂点/ピクセルシェーダのバージョン 1.1) 相当の機能だけで 無理矢理実装した技術デモです。というかほとんど思い付きの一発ネタです。
技術要素としてはなどがあります。
- HDR (High-Dynamic Range) Rendering?
- IBL (Image-Based Lighting)
- Glare (Afterimage/Bloom/Ghost/Star) Generation
- Fresnel Effect (Specular Reflectance)
- FSAA (Full-Scene Anti-Alias)
- Motion Blur
|
|
Screen Shots ! |
|
|
System Requirements |
機能的には DX8 相当しか使っていませんが、 ユーティリティ等の都合上開発は DX8.1b SDK で行っています。
- Intel(R) 80x86 もしくは互換系 CPU
- DirectX(R) 8.1b 以降のランタイム
- Vertex/Pixel Shader Ver.1.1 以降をハードウェア実装しているビデオカード (早い話が NVIDIA GeForce3 以上)
- ハードドライブに少なくとも 40MB (可能なら 200MB 以上) の空き(大汗
リファレンス・ラスタライザでも動作はしますが、極めて不愉快な思いをすること請け合いです (0.04 FPS etc.)。 NVIDIA GeForce FX / ATI RADEON 9500/9700 あたりなら極めて快適に動作します。
RADEON シリーズの場合、RADEON 9500/9700 以降でないとキューブマップ にミップマップを使用できないため、9000 以前のカードでは相当画質が劣 化すると思われます。
|
|
Notes |
最初に実行する時は、下の理由により起動に 20〜30 秒かかります。 次からは 2〜3 秒で起動します。二回目以降なら 1〜3 秒程度です。
- マルチサンプル数/ライティング情報 (HDR 環境マップ)/露光値の組み合 わせ毎に、20〜40 MB 程度の大量のキャッシュファイルを生成します。 初めての組み合わせではキャッシュファイル生成作業に 10〜20 秒程かか ります。
HDR 用の画像やマルチサンプリング処理のため、かなりの VRAM を消費します。 画面解像度の変更が出来ますが、64MB VRAM のカードでは 1024x768 程度が限界だと思います。 現状チェックが甘いので、あまり大きなサイズには変更しない方が無難だと思います。
嗚呼…無茶苦茶な仕様で申し訳ありません…。
|
|
Download !! |
実行に最小限必要なファイルです。
mshdribl_1_0.zip (1,994KB) Minmum executable 下は追加用のライト環境マップです。 media フォルダ以下を mshdribl の media フォルダにコピーし、 実行中 Ctrl+L キーで *.lem ファイルをロードしてください。
mshdribl_rnl.zip. (1,596KB) Additional HDR light environment file mshdribl_stpeters256.zip. (1,456KB) Additional HDR light environment file mshdribl_uffizi256.zip. (1,496KB) Additional HDR light environment file
|
|
Techniques |
- HDR レンダリングの仕組み
- レンダリングは全て HDR に基づいたイメージベースドライティングです。 基本的に カラーレンジの圧縮 (輝度 1.0 を例えば 8.0 相当として処理) を利用しています。 そのまま実装すると当然画質が激しく劣化してしまう訳ですが、 マルチサンプリングを利用してこれを防いでいます。
興味のある方は、キャッシュファイルとして生成された連番画像 (media/Caches/*_80〜*_87.tga) を覗いてみてください。 各画像は輝度を 1/8 に圧縮しただけの全く同じ画像のようにに見えますが、 実際には微妙に異なっています。 *_80.tga の画像輝度を単純に 8 倍すると劣化した画像が生成されますが、 *_80.tga 〜 *_87.tga を 1 枚ずつ加算してゆくと劣化していない画像を復元できます。
具体的に説明します。 ここに、0 〜 7 までの整数輝度を持つピクセルがあるとします。この輝度を 1 / 8 に圧縮した画像を 8 枚描画し、最後に 8 枚全てを加算して元の輝度に戻します。 すると当然、丸め誤差により全てのピクセルの輝度は 0 になってしまいます(整数の 1 / 8 はゼロ)。 そこで、圧縮した 8 枚の画像を描画する際、それぞれの画像毎に 0 〜 7 までの 個別のオフセットを加算してから 1 / 8 にします ( (luminance + 0 〜 7) / 8 )。 すると、桁落ちの発生する輝度が画像毎に変化します。
オフセット=0 の画像では、 0,1,2,3,4,5,6,7 のそれぞれの輝度は、圧縮後には 0,0,0,0,0,0,0,0 になります。
オフセット=1 の画像では、 圧縮後の輝度は 0,0,0,0,0,0,0,1 になり、
オフセット=7 の画像では 0,1,1,1,1,1,1,1 になります。
圧縮前の輝度情報が 8 枚とも全て同じであれば、これらの画像を一枚ずつ加算すると、 元の精度を復元できることになります。 この理屈を応用しています。 実際のデモでは FSAA やモーションブラーにより同じ画像ではありませんが、それなりの質で復元できます。 モーションブラーは特に誤差が出ますが、元々動いている時だけのため、実際にはあまり問題が表面化しません。本来ならピクセルシェーダ内で処理でき、このような大量のテクスチャは不要なのですが、 ピクセルシェーダバージョンの都合でレジスタ精度が 8 bits しか保証されないため、やむなく複数のテクスチャに予め仕込んでいます。
また、予め作成したテクスチャを使う都合、デモではこのアルゴリズムが 適切に働くための条件を満たしていないことが多い (少なくとも 100% 鏡面反射もしくは 100% 拡散反射のマテリアルでなければならない) ため、 背景以外は破綻して画質が多少劣化しています (背景もちょっと変ですが)。
デモ中 'o' キーを押している間は、この精度向上アルゴリズムが無効になります。 見比べてみると画質の違いが判…らないかも知れませんね(汗 画面を止めた状態で「背景」を見比べれば判るとは思いますが…。
- グレア生成
- レンダリング画像は HDR 情報を持っているため、 最後に高輝度成分 (輝度 1.0 を超えているピクセル)を抽出し、 グレアおよび残像を生成しています。 グレアのタイプにもよりますが、縮小したバッファ上でおよそ 20〜30 パ ス程度のピクセルシェーダによる塗り潰しを行っています。 グレア生成の具体的なプロセスについては、 コラム: GDC 2003 Presentationをご参照ください。
※カメラや眼のグレアは、本来なら高輝度ピクセルだけではなく全てのピクセルで発生します。 しかし、ダイナミックレンジの不足から画像全体がぼやけるだけになるため、高輝度成分のみに グレアを発生させています。
|
|
References |
"The RADIANCE Picture File Format", http://radsite.lbl.gov/radiance/refer/Notes/picture_format.htmlLight Probe Images courtesy of Paul Debevec, http://www.debevec.org/Probes, used with permission.
本ページの御意見・御感想は
ホームページに戻る
E-Mail: masa@daionet.gr.jp