高度なライティング & DirectX
グラフィックスの将来展望
David Blythe (Architect)
Kev Gee (Software Design Engineer)
Windows® Graphics & Gaming
Microsoft Corporation
Agenda
高度なライティング テクニック
DirectX グラフィックスの将来展望
高度なライティング テクニック
ゲーム内でよりリアルなライティングを
達成する方法
優れたライティングは品質にとって重要
2つの異なるテクニック
D3DX を使ってそれぞれを容易に実装す
る方法
背景
基本概念
ライティング環境
光の伝播
テクニックが何を可能にするかを理解す
るために必要な概念
ライティング環境
ライティング環境は、オブジェクトを照らす
全ての光
平行光源や点光源だけではない
面光源や壁・空・離れたオブジェクト・自分自身か
ら反射した間接光
サーフェイス上の全ての点について、
RGB ライト値に満ちた半球が存在
ライティング環境
各点での入力光を全て計算する伝統的手法は
負荷が高い
半球全体での積分が必要
通常、低解像度ディフューズ キューブ マップで行う
か、単純なライティングを使った近似
本講演のテクニックは全ライティング環境を使用
正確な近似を使用
リアルタイム – ディフューズ キューブ マップより高
速
複数の平行光源より優れている
光の伝播
光の伝播とは、光がジオメトリやマテリアルと
どのように相互作用するか
グローバル イルミネーション
反射と色の放出
影
表面下散乱
動的なライティング環境をリアルタイムで計算す
ることは困難
静的ライティングについては、ライト マップが使える
ライティング図
入射放射輝度
(球状環境マップ)
出力放射輝度
伝播した
入射放射輝度
表面下散乱
ライティング環境
光の伝播
伝統的なライティング
SH 放射照度環境マップ
事前計算済み放射輝度伝播
議論するテクニック
球面調和 (SH: Spherical harmonic ) は
放射照度 (irradiance) 環境マップを表す
動的面光源だが、単純な光の伝播
事前計算済み放射輝度伝播
(PRT: Precomputed Radiance Transfer )
複雑な光の伝播を持つ動的面光源だが、
剛体オブジェクトのみ
SH 放射照度環境マップ
名前にビビることはない
放射照度とは単に「ある点に入ってくる全ての光」
を意味する
球面調和を知っている必要はない
ゴールは、オブジェクトの全ての点で
総入射光を見つけること
これを行う個別の方法
平行光を仮定し、N・L
ディフューズ キューブ マップを N でインデックス化
SH 放射照度環境マップ: cont.
このテクニックは光を球関数として扱う
球面調和 (SH) を使って、ディフューズ キューブ マップ
をチャンネルあたり 9つの係数で近似する
したがって、64x64x6 のディフューズ キューブ マップの
代替として、カラー ライティングがたった7つの float3
シェーダ定数となる
動的で複雑なライティング環境についてディフュー
ズ ライティングを計算する非常に高速な方法
ディフューズ ライティングについては、
近似誤差が数パーセントの正確さ
伝統的なライティングを使うと、シェーダは2つのラ
イト、5つのライトなどを扱う。このテクニックが意味
することは、シェーダの複雑さがライティングに依存
しなくなること
SH 放射照度環境マップ 対 PRT
次のテクニック PRT と違って
事前計算ステップをほとんど持たない
セルフ シャドウやグローバル イルミネーション
のような複雑な光の伝播はない
変形可能なオブジェクトを扱う
これと PRT を組み合わせるのは容易
どちらのテクニックも SH 係数内に
ライティング環境が必要
従って、いったん持てば、これでもPRTでも
オブジェクトを照明できる
SH 放射照度環境マップを行う方法
次のような D3DX 関数を使ってライティングを
SH 係数に近似:
D3DXSHProjectCubeMap
D3DXSHEvalConeLight
D3DXSHAdd, D3DXSHScale, D3DXSHRotate
SH 係数からシェーダ用の定数を計算
シェーダはその定数と法線を使って、
頂点 / ピクセルでのディフューズ色を計算する
詳細については SDK サンプルを参照
SH 放射照度環境マップ HLSL シェーダ
// 入力: 法線と 7 つの float4 定数
//
cAr, cAg, cAb, cBr, cBg, cBb, cC;
// 出力: ディフューズ色
x1.r = dot(cAr,vNormal);
x1.g = dot(cAg,vNormal);
x1.b = dot(cAb,vNormal);
7 定数
11 vs_1_1 命令
グレースケールのライトなら
もっと少ない
float4 vB = vNormal.xyzz * vNormal.yzzx;
x2.r = dot(cBr,vB);
x2.g = dot(cBg,vB);
x2.b = dot(cBb,vB);
float vC = vNormal.x*vNormal.x - vNormal.y*vNormal.y;
x3 = cC.rgb * vC;
float3 diffuseColor = x1 + x2 + x3;
複数の SH ライティング環境をブレンド
空間内の全点がディフューズライティング環境を持つ
暗い隅のライティングは大きな明るい部屋の真ん中とは異なる
全点でライティング環境を格納することは
現実的でない
従って、ある頻度でのみ
オブジェクトの移動に従って、
最も近いライティング環境間でブレンド
各サンプル点で生成するには、
キューブ マップをオフラインでレンダリングして、
D3DXSHProjectCubeMap で SH 係数を近似
不正確なブレンド
光源が本当に離れていないと、線形ブレンドは
不正確になる
光源
正確なライト方向
ライト方向
(近い壁からの間接光の場合もある)
オブジェクトの新しい位置
移動するオブジェクト
正しくない線形ブレンド結果
事前計算済み放射輝度伝播 (PRT)
動的ライティング環境と組み合わせた
複雑な光の伝播を可能に
伝統的なテクニックでは困難
伝統的なライト マップと違い、
光の伝播が動的なライティング変更に対応
ディフューズ マテリアルがベスト – 光沢も可能だ
が負荷が高い
シェーダ内での特殊な扱いなしで、
次のものを提供:
ソフト セルフ シャドウ
内部反射と色放出
表面下散乱
しかし、制限がある
PRT の実行方法
圧縮した PRT 伝播係数をメッシュ用に生成
ライティング環境に依存しない光の伝播を計算
頂点単位、あるいはテクセル データ単位で作成
実行は簡単 – D3DX を使うだけ (算術演算不要)
時間がかかる (秒単位) ので、アート作成中に行う
ライティング環境を球面調和 (SH) 係数に変換
リアルタイムでもオフラインでも実行可能
D3DX API 呼び出しを使う (算術演算なし)
先のテクニック (SH 放射照度環境マップ) と
同じアイデア
上の内容をシェーダ内で使って、
ディフューズ色を計算
DirectX SDK Update (Summer 2004) に
おける D3DX PRT API の更新
新しいモジュール型設計
より柔軟なシミュレータ
適応型メッシュ テセレーションを統合
3つのインターフェイス
PRT シミュレータ エンジン: ID3DXPRTEngine
PRT バッファ: ID3DXPRTBuffer
圧縮 PRT バッファ: ID3DXPRTCompBuffer
PRT のオフライン部分
ID3DXMesh を使った初期化エンジン
パラメータ設定
D3DXSHMATERIAL 配列
サンプリング情報
オプションのテクスチャ反射率
ループ、光の伝播をシミュレートする
Compute* を呼び出す
ID3DXPRTBuffer 内で累積合計
圧縮しシェーダ データを抽出
詳細については SDK サンプルを参照
PRT の実行時部分
D3DXSHEval*() を呼び出し、オブジェクト空
間のライティング環境を L’ として SH に変換
これをオフラインで行いシーン内に格納してもよ
い
CPU 上で定数データを計算
頂点単位あるいはテクセル単位で、
圧縮バッファからデータを格納
PRT HLSL シェーダ
float4 vAccumR = 0, vAccumG = 0, vAccumB = 0;
for (int i=0; i < (NUM_PCA/4); i++)
{
vAccumR += vPCAWeights[i] * aConsts[nOffset+1+(NUM_PCA/4)*0+i];
vAccumG += vPCAWeights[i] * aConsts[nOffset+1+(NUM_PCA/4)*1+i];
vAccumB += vPCAWeights[i] * aConsts[nOffset+1+(NUM_PCA/4)*2+i];
}
4 PCA の場合
float4 vDiffuse = aConsts[nOffset];
vDiffuse.r += dot(vAccumR,1);
vDiffuse.g += dot(vAccumG,1);
vDiffuse.b += dot(vAccumB,1);
11 vs_1_1 命令
NUM_CLUSTERS * 4 定数
頂点ごとに 1 float4 + 1 int
8 PCA の場合
14 vs_1_1 命令
NUM_CLUSTERS * 7 定数
頂点ごとに 2 float4 + 1 int
反射率の扱い
最初のオプションは、サーフェイスの反射率
(ディフューズ反射率) を PRT 信号に乗算す
ること
反射率が信号と同じ頻度なら、これは妥当
テクスチャを使って反射率を乗算
より高い頻度でテクスチャを格納
高い頻度のテクスチャは、
低い頻度のシェーディングの不具合を隠す
適応型メッシュ テセレーション
各頂点で光の伝播方法を計算するので、頂
点が十分にないと、頂点単位 PRT はうまく
見えない
これを解決するために、メッシュをテセレー
ションしてより多くの頂点を持つようにする
PRT シミュレータは統合されたメッシュ テセ
レーションを持ち、必要な領域に非均一に頂
点を追加できるよう援助する
詳細情報:
SDK 内のサンプル
SDK 内のプログラミング ガイド
Ravi Ramamoorthi と Pat Hanrahan による “An
Efficient Representation of Irradiance Environment
Maps” , SIGGRAPH 2001
Peter-Pike Sloan, Jan Kautz, John Synder による
“Precomputed Radiance Transfer for Real-Time
Rendering in Dynamic, Low-Frequency Lighting
Environments” , SIGGRAPH 2002
[email protected] にメールをください
Agenda
高度なライティング テクニック
DirectX グラフィックスの将来展望
DirectX グラフィックス将来展
望
我々はどこにいるのか ?
我々はどこに行く必要があるのか ?
我々はどうやってそこにたどり着くか ?
お願いしたいこと
我々はどこにいるのか ?
DirectX 9.0c がリリースされました !
SM 3.0 ハードウェアが利用可能に
命令数、差分、セントロイド、動的フロー制御、
入れ替え、インスタンス
エフェクト / HLSL 内の改善
ローカルな変形を持つ PRT
新しいサンプル フレームワーク
新しいツール – PIX、プレビュー パイプライン
XNA イニシアティブ
我々はどこにいるのか ?
良い
ポスト処理の時代
高ダイナミックレンジ (HDR) 画像
ぼかし、グレア、被写界深度…
優れたローカル ライティング (皆さんの役割)
Oren-Nayer, Cook-Torrance, …
グローバル (的) イルミネーション
影 (シャドウ ボリューム、深度マップ)
アンビエント遮蔽
事前計算済み放射輝度伝播 (PRT)
我々はどこにいるのか ?
悪い
タイトル開発に時間がかかりすぎる
シェーダ モデル 2 はあまりに多くのことが可能に !
どうやったらこのテクノロジを効率的に使えるのか ?
うわっ、俺の仕事はどこに ?
依然として、グラフィックス カードのバリエーション
が多すぎる
多数のカードをターゲットにすると時間がかかる
少数のカードをターゲットにするとお客が減る
どうやって液晶とモニターとTVの XYZ を駆使する
のか ?
歪像ピクセル、(非)正方形ピクセル
我々はどこにいるのか ?
ひどい
ドライバを更新したらタイトルが落ちた
この BSOD は何か ?
どのシェーダモデルをターゲットにすべきか
1.0, 1.1, 1.2, 1.3, 1.4,
2.0, 2.0a, 2.0b, 3.0?
我々はどこに行く必要があるのか?
有益なエコシステムを思い出してください
顧客が PC を購入するとき
グラフィックス ハードウェア、他のハードウェア的
要素と
OS を一緒に購入
これは、「ゲーム プラットフォーム」
顧客はエンターテインメントを希望
エンターテインメント == すぐに動作し、
説得力のある経験
エンターテインメント != どうして動かないかを
見つけること
我々はどこに行く必要があるのか ?
ISV はゲーム アプリケーションや
開発コンポーネントを提供
ゲームは定期的に説得力のある新しい経験と
共に現れる
IHV はグラフィックスを提供
新機能を持つ新しいハードウェア
Microsoft は OS を提供
新機能を持つ新しい OS
Microsoft はプラットフォームの定義を
コーディネートする
我々はどこに行く必要があるのか ?
ゲーム プラットフォームとしての Windows
安定性
セキュリティ
可用性
一貫性
テクノロジ
→ Windows Graphics Foundation
(閑話休題、命名について)
Windows Graphics Foundation == WGF
Direct3D API の新しい名前
リリースは WGF m.n{.o}
‘m’ は重要で新しいアーキテクチャ
DirectX7->DirectX8 を考えてください
~5 年のタイムフレーム
‘n’ は新機能 / 新 API
DirectX8.0->DirectX8.1->DirectX9 を考えてください
~1 年のタイムフレーム
‘o’ はサービス リリース
(本題に戻ります…)
安定性 & セキュリティ
全てのデスクトップ グラフィックスは
DirectX を使って動作
新しいドライバ モデル
Longhorn の大きな改善
ほとんどシームレスなエラー回復
グラフィックス ドライバからの BSOD はない
より多くの処理がユーザーモードに移行
カーネル処理の単純化
厳しいコンテキスト レベルのアクセス制御
providers
新しいドライバ モデル
ISV
Application
GDI+
Direct3D
Win32K
DXG
MS
IHV
Application
ユーザー
空間
セッション
空間
GDI+
Direct3D
U-M Driver
Win32K
CDD
Kernel Display Driver
DispLdr
Videoport
Miniport
カーネル
空間
DXGkrnl
K-M Driver
可用性
仮想化
GPU は複数のアプリで利用可能
GPU 処理のスケジューリング
Crawl: バッチをスケジュール
Walk: コンテキストをスケジュール
Run: プリエンプティブなコンテキスト
スケジューリング
仮想 GPU メモリ
Crawl: 事前読み込みが必要なサーフェイス
Walk: 要求に応じて読み込むサーフェイス
Run: 要求に応じたサーフェイスからの
ページング
一貫性
グラフィックス ハードウェアのバリエーション
を削減
すぐに始める、数年でメリットが明らかになる
より注意深く振る舞いを指定
2つの数をどうやって加えるか
三線形フィルタリングとは何か
マルチサンプル ＡＡ はどのように動作するのか
機能 CAPS を排除
パフォーマンスと “major caps” でスケール
Major cap == WGF version
テクノロジ
ステップ 0
不十分な部分を修正
安定性、セキュリティ、一貫性、パフォーマンス
不要な部分を取り除く
固定機能パイプライン部分
ステップ 1
プログラミング モデルの進化
より表現力豊かなプログラミング可能性
ステップ 2
アーキテクチャの進化
新しい種類のアルゴリズムを可能に
ステップ 0 に進む
不要な部分を取り除く
固定機能処理
頂点ライティング
フォグ
アルファ テスト
プリミティブ
三角形ファン
ポイント スプライト
フォーマット
FVF 頂点
レガシ テクスチャ / RT フォーマット
プログラミング モデルの進化
共通シェーダ コア
プログラマブル シェーダ ステージに使用
VS, PS, …
密接に特徴づけ (32-bit float)
共通シェーダ コアの特徴
整数命令セット
インデックス化した一時レジスタ
単純化と組織化
リソース
ステージからステージへの連携
プログラミング モデルの進化
上位レベルプログラミングの進化
将来は HLSL
アセンブリ言語はデバッグ用のみ
将来のプログラミング構成体
シェーダ間で共有するサブルーチン
エフェクト フレームワークの進化
さらに拡張
オーサリング アプリケーション
ランタイム アプリケーション
プリシェーダ、アノテーション…
アーキテクチャの進化
新しいパイプライン ステージ
ジオメトリ シェーダ (WGF 1.0)
ストリーム出力 (WGF 1.0)
テセレータ、ポスト テセレータ VS (WGF 1.0+)
効率性の改善
ステート管理
HDR 画像フォーマット
法線マップ圧縮
テクスチャ比較フィルタ
~パーセント近い
WGF レンダリング パイプライン
固定機能
プログラマブル
メモリ
入力
アセンブラ
頂点
シェーダ
テセレータ
VS
サンプラ
頂点
インデックス
テクスチャ
バッファ
バッファ
ジオメトリ
シェーダ
セットアップ ピクセル
ラスタライザ シェーダ
サンプラ ストリーム出力
メモリ
テクスチャ
ストリーム
バッファ
出力
合成
サンプラ
テクスチャ
深度
レンダー
ステンシル ターゲット
ジオメトリ シェーダ
プリミティブ単位で処理
隣接性を含む
トポロジ処理
輪郭エッジ
押し出し、止め継ぎ、べべル
データ増幅
点 → ジオメトリ
フィン、ファー
! テセレーション
プログラマブル セットアップ
平面式、重心座標パラメタの計算
「ジオメトリ シェーダはすばらしい」
- Peter-Pike Sloan
その他の改善
ストリーム出力
効率的な 「頂点バッファへのレンダリング」
配列化したリソース + ジオメトリ シェーダ
単一パスでキューブ マップにレンダリング
より多くのリソース
一時、サンプラ、定数、テクスチャ…
ステートの削減、組織化
より効率的なステート変更
バッチ オーバーヘッドの削減
10倍の改善がターゲット
タイムフレーム
Longhorn での新しいドライバ モデル
crawl, walk, run の順序
WGF 1.0 in Longhorn
どちらも 2005年 の Longhorn ベータで
次は ?
SDK の更新は続く (今年の末)
来年 WGF 1.1 実作業開始
1.0 リファレンス実装が先
警戒してください
鋭利なツール !
動的条件と SIMD 処理はうまく調和しない
ジオメトリ シェーダはテセレータではない
HW 設計はテクスチャ命令より ALU 命令の
ほうが頻繁だと仮定している
キャッシュ スラッシングも
共通場所での初期の深度処理
2パスに延びたシェーディング
予期せぬエッジ ケースが発生するかもしれない
我々はどちらを向いているのか ?
ジオメトリの複雑さ
輪郭エッジ
テクスチャのパラメータ化
変移 (ディスプレースメント)
スキニング & モーフィング
マテリアルの複雑さ
繰り返し応答
粗さ (ジオメトリの複雑さ ?)
表面下属性
光伝播の複雑さ
面光源
(セルフ) シャドウ
内部反射
WGF 1.0 の後
マルチサンプル AA & スーパーサンプル AA に
再取り組み
より一貫性のある望ましい振る舞い
倍精度浮動小数点
いずれ必要になる
高次サーフェイス
計算 >> メモリ バンド幅のとき
自動リソース管理
共有サブルーチンなど
プログラマブル ブレンディング
HLSL / エフェクトのアプリケーションとの統合
WGF 1.0 のさらに後
その他のテクノロジに目を向け続ける
レンダリング
レイトレーシング
フォトン マップ
ラジオシティ
ジオメトリ モデリング
物理
衝突
IK, 運動学, …
依然として進むべき長い道のり
Akeley 2003
36000倍のパフォーマンス改善が必要
フレームレート、大きなディスプレイ、AA、ステレオ、
FOV…
年間成長率 2.0倍 (複利) で約15年
トリックは効率性を失わずに改善を達成する
こと !
前向きに挑戦
汎用目的と特殊目的とのバランス
例えば、RISC 対 CISC
サンプラをシェーダ コードに移すべきか ?
メモリ アクセス
構造体の配列 対
配列の構造体
どうやって計算を構造化すべきか ?
汎用目的の CPU と同じではない !
前向きに挑戦
並列化を最大に
遅延隠蔽テクニックを使う
計算 >> メモリ バンド幅 と仮定する
コミュニケーションをどうやって構造化する ?
ステージ ↔ ステージ バッファリング
読み取り-修正-書き込みメモリ操作を探求
プログラミング モデルをどうやって表現する ?
革新を可能にするが、一貫性を保つ
まとめ
安定性
一貫性
セキュリティ
WGF
On
Longhorn
可用性
テクノロジ
お願いしたいこと
DirectX 9.0c にアップグレードしてください
シェーダ モデル 3.0 を検討してください
DirectX SDK Summer Update 2004
HLSL とエフェクトの改善
PRT
PIX、プレビュー パイプライン
標準セマンティック & アノテーション
新しいサンプル フレームワーク
ベータ プログラムに参加してください
パブリックとベータの DirectX ニュースグループ
教えてください
何が皆さんの障害になっているのか ?
機能のリクエスト
[email protected] にメールしてください
ご質問は ?
?
?
?
?
?
?
?
?
?
?
?
お知らせ
SDK & 日本語ドキュメント送付申し込み
出口の箱に名刺を入れてください
DirectX Graphics Meeting (9/8)
開発者の方と WGF の仕様などに対する
フィードバックを個別に1時間づつ議論
講演終了後、川西にお問い合わせください
© 2003-2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
© Copyright 2024 ExpyDoc
