Transcript 高度なライティング & DirectX グラフィックスの将来展望
高度なライティング
& 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; //
出力
:
ディフューズ色
7
定数
x1.r = dot(cAr,vNormal); x1.g = dot(cAg,vNormal); 11 vs_1_1
命令 グレースケールのライトなら
x1.b = dot(cAb,vNormal);
もっと少ない
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 MS IHV
Application GDI+ Direct3D
ユーザー 空間
Application GDI+ Direct3D U-M Driver Win32K DXG Kernel Display Driver Videoport Miniport
セッション 空間 カーネル 空間
Win32K CDD DispLdr 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
ニュースグループ 教えてください 何が皆さんの障害になっているのか 機能のリクエスト
?
にメールしてください
ご質問は
?
?
?
?
?
?
?
?
?
?
?
?
お知らせ
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.