【KANSAI CEDEC 2015】FINAL FANTASY 零式HDにみる 新しいHDリマスター

FINAL FANTASY 零式HD にみる 新しいHDリマスター 株式会社ヘキサドライブ 開発部 チーフテクニカルディレクター 開発部 プログラマー 岩崎 順一 山口 裕也 1 / 127

会社紹介 株式会社ヘキサドライブ 設立2007年 大阪本社 / 東京開発 社員数64名(2015年1月現在） ©Q Entertainment Inc. ©SEGA ©Konami Digital Entertainment / GREE ©Konami Digital Entertainment ©2010 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN:TETSUYA NOMURA ©2012 SQUARE ENIX CO., LTD. All Rights Reserved. ©CAPCOM CO., LTD. 2006,2012,2014 ALL RIGHTS RESERVED. ©2013 Nintendo / PlatinumGames Inc. 過去に制作したタイトル ⇒他にも多数！！ 2 / 127

FINAL FANTASY 零式 (株式会社スクウェア・エニックス) プラットフォーム PlayStation Portable 2011年10月27日発売 発売当時 月間/週間ゲームソフト販売ランキング メディアクリエイト 週間ソフトセルスルーランキング ファミ通 首位！ 海外でも 初動売上は47.2万本を記録 評価が高い 発売を望む声が多かった FINAL FANTASYの名を冠する作品の中でも アクション性が高い作品 © 2011 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN : TETSUYA NOMURA 3 / 127

FINAL FANTASY 零式 HD (株式会社スクウェア・エニックス) プラットフォーム PlayStation4 XboxOne 2015年3月19日発売予定 マルチプラットフォーム展開 ２プラットフォーム同時開発 各国語 字幕ローカライズ対応 日本語・英語・フランス語・イタリア語・ドイツ語・ スペイン語・韓国語・中国語 (簡体字・繁体字) 原作からのバランス調整・隠し要素追加 グラフィックのリファイン ＆ HDリマスター © 2011,2015 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN : TETSUYA NOMURA 4 / 127

本日のトピックス 開発のワークフロー HD化にあたっての取り組み -世代を越えた “新生”携帯機PSPからの３世代とび越えた『HD化』 グラフィックのリファイン & リマスター 新しい世代のグラフィックトレンド導入 物理ベースライティング / DirectX11世代での技術的な挑戦 原作の演出意図を考慮した新描画エンジンと従来の描画エンジンの共存 ポストエフェクトフィルター技術解説 HDRとLDRが混在する特殊条件下での辻褄を合わせたLDR合成 5 / 127

PSPからの主な変更点 グラフィック品質向上 フルHD化 1920x1080 対応 物理ベースレンダリング モデルデータのリファイン 光学フィルター 等々… プレイ中の感触の調整 カメラの角度 キャラクターの移動速度 盛り沢山!! ゲーム難易度選択追加 & バランス調整 低難度モード ＆ 高難度モード追加。ユーザーのプレイスタイルを考慮 6 / 127

HD化にあたっての取り組み -世代を越えた “新生”- 開発のワークフロー 7 / 127

フルHD化 1920 x 1080 両プラットフォーム共に 1920x1080 (1080p) 同じ体験を可能にするため 最後の最後までパフォーマンス最適化!! PSP PS4 / XboxOne 480 x 272 1920 x 1080 8 / 127

フルHD化 1920 x 1080 272 480 約17倍の描画面積！ 1080 1920 9 / 127

PlayStation Portable 480 x 272 10 / 127

PlayStation4 / XboxOne 1920 x 1080 11 / 127

UIのフルHD化 PlayStation Portable 480 x 272 12 / 127

UIのフルHD化 PlayStation4 / XboxOne 1920 x 1080 13 / 127

開発指針 PSP版原作の完全移植 当時の演出や表現を再現して同じ体験を可能にする。 PSPの描画命令をエミュレーションすることで対応することに決定 過去のノウハウが活かされたため素早く着実に進めることができた ポストエフェクトフィルターなどプログラムでリッチに。 ⇒グラフィックリソースに影響与えずに品質を上げる 2D系の表示物/メニュー関連は1080p向けにリメイク 14 / 127

エミュレーション実装の結果 15 / 127

更なる品質を！ ほぼ動くようになった段階で追加オーダー入りました…!! PS4/XboxOneに見合った品質に !! 次世代らしい品質に引き上げられないだろうか？ SQUARE ENIX × HEXADRIVE 技術のコラボレーション 物理ベースレンダリング 3Dデーターリファイン •ヘキサドライブで実装 •プログラム技術で光学エフェクトなど魅力あるビジュアルへ •SQUARE ENIXでHD品質を担保 •次世代のソフト開発を経て培ったグラフィック技術 16 / 127

描画フローの完全置き換え!! 原作には元々無かったものを多数新規追加 シャドウ / ディファードレンダリング / 物理ベースマテリアル 被写界深度 / レンズフレアなど光学エフェクト etc… 描画フローを大幅に刷新 半透明描画を全て後段パスへ移動。天球をHDR化。 背景の多層重ね貼りはGバッファマルチテクスチャへ移動 今作はPSP→DX11世代へのHD化で 世代が違いすぎて描画フローが全くの別物だった 17 / 127

ディファードレンダリングの導入 近年のゲームCGでは標準的なレンダリングフロー 長所 シェーディング時に付加情報を得やすい。(速度 / 材質 / マスク情報 etc..) ライティング個数制限がなくなる。(シェーダーの簡略化) 短所 メモリ帯域を多く消費する。(Gバッファ生成とそのアクセス) 半透明オブジェクトが使えない。 ⇒半透明不可は致命的なため別途対策が必要。(後描きでForward+など) 18 / 127

PSPの描画 / HD版の描画 フロー 遠景 背景 キャラクタ （天球 etc…） （ライティングなし） （ライティングあり） キャラクタ 半透明 VFX (ソート) PSP版の描画 フィルター HUD (2Dメニュー) HD版の描画 固定パイプライン カラー描画 プログラマブルシェーダー無し 高度なライティング計算は無い 移行 シャドウ生成 Gバッファ生成 / ディファード HDR光源計算 物理ベースライト トーンマッピング シャドウ 生成 Gバッファ 生成 (MRT) 光源計算 IBL HDR 天球 (HDR) 光学系 フィルター VFXがPSPの状態を維持 !!? LDR トーン HUD VFX フィルター マッピング (半透明ソート) (2Dメニュー) 19 / 127

全挿げ替えの大手術 新しい技術検証と新描画フロー刷新 同時進行で検証しながら実装 社内でも過去に類を見ない速度で再構築が進んだ エミュレートを撤廃 直接描画に全変更 物理ベース技術検証 IBL 1段階目 ディファード導入 描画順序再構築 物理ベースシェーダー IBL設置ツール ２段階目 HDR & LDR描画構築 光学フィルター 影 DCCツール拡張検証 3段階目 新生システムが構築された段階で量産開始。 20 / 127

HDRとLDR Legacy vs Modern 実装を変えてしまうと全く見た目が違うものになってしまう問題 ・フォグ描画を霧以外の用途に活用しているフェイク表現 ・フォグの濃度がゲーム演出にも密接に関連 ・カラールックアップテーブル(CLUT)でのカラー補正機能 ・RGB輝度を抽出して光る演出をしているグレア表現 21 / 127

HDRとLDR Legacy vs Modern PSPからのHD化移植ではPSP当時のレガシーなシステムを 再利用/共存することも避けては通れない事案。 『リメイク』ではなく『少しリッチなHDリマスター』 物理ベースレンダリング CookTorrance ＋ リニア空間 HDR LDR PSP Lambert & カラー描画 + sRGB空間 22 / 127

HDRとLDR Legacy vs Modern プロジェクトの大きな課題 両方の全く異なるアーキテクチャを共存させる 特殊な 連携 / 結合 物理ベースレンダリング CookTorrance ＋ リニア空間 HDR LDR PSP Lambert & カラー描画 + sRGB空間 23 / 127

HDRとLDR Legacy vs Modern 遥かなる遺産 - Legacy Imprement PSP当時の様々な創意工夫が作品のビジュアルを構成 トーンカーブ エフェクト 線形フォグ 平行点光源 Bloomグレア 背景ぼかし 24 / 127

HDRとLDR Legacy vs Modern 演出意図が変わってしまうことだけは避けたい!! MISSION発生!! 一部の描画はPSPエミュレートで行う必要がある !! 残さなければならない実装が存在する 25 / 127

PSPエミュレートそれぞれの対応 フォグ -fog当時はNear/Farを使ったシンプルな線形補間 物理ベースでの光散乱をテストしてみたが濃度と輝度が全く一致しなかった ⇒エフェクト的にフォグ描画を活用している箇所が全滅 フォグ濃度計算結果(0～255)をGバッファに格納してHDRトーンマップ後にLDR合成 26 / 127

PSPエミュレートそれぞれの対応 トーンカーブ補正 –tone curve correctionカラーテーブルを参照して輝度から変換する方式。 ⇒当時はこれによってPSPでありながらも柔軟な色補正を実現していた 1Dテクスチャ & シェーダー でCLUTを再現してLDR空間で実装 トーン補正OFF トーン補正ON 27 / 127

PSPエミュレートそれぞれの対応 被写界深度 –depth of fieldリアルタイムカットシーンのみ背景描画後に全画面ぼかし ⇒背景はぼけてキャラクターは後描きで鮮明にして表現されていた 被写界深度は距離計算の辻褄が合えば置換可能 !! リメイク刷新対象へ 刷新の詳細は後述 28 / 127

PSPエミュレートそれぞれの対応 エフェクト -VFX専用の内製ツールで緻密な調整が行われていた ⇒種類が膨大(5000種類超え)で、ブレンドモードも様々。 PSPハードウェア固有の特殊なブレンド機能も活用されていた…!!! 全VFXをHDR化するとすればそれはリメイクを意味する多大なコスト 両社協議の結果、HDRへの移行は行わずLDRのままで続投と判断 トーンマッピング完了後にエフェクトを後合成でLDR空間で描画 ただ、まだ諦めてはいない…!! HDRにアプローチする別の手法を後述 29 / 127

PSPエミュレートそれぞれの対応 二方向の全く異なる方向性をまとめ上げることが 果たしてできるのか!? 出来ました…!! 30 / 127

Gバッファのレイアウト R G B A RT0 Albedo.R Albedo.G Albedo.B AO RT1 Normal.X Normal.Y Normal.Z MASK RT2 Roughness Metalness Skin Emissive RT3 Velocity.X Velocity.Y FOG R8G8B8A8(sRGB) R10G10B10A2 R8G8B8A8 Velocity符号 R10G10B10A2 (X:1bit Y:1bit) PSPのエミュレーションのために幾つかの特殊な構成が必要 31 / 127

Gバッファのレイアウト 法線の裏表を表現する必要があったためZ値も 背景とキャラクターの判定マスク RT0 Albedo.R Albedo.G Albedo.B AO RT1 Normal.X Normal.Y Normal.Z MASK RT2 Roughness Metalness Skin Emissive RT3 Velocity.X Velocity.Y FOG 肌表現を行うための対象マスク R8G8B8A8(sRGB) R10G10B10A2 R8G8B8A8 Velocity符号 R10G10B10A2 (X:1bit Y:1bit) PSPの線形フォグ(0.0～1.0) 32 / 127

Gバッファのレイアウト R G B A RT0 Albedo.R Albedo.G Albedo.B AO RT1 Normal.X Normal.Y Normal.Z MASK RT2 Roughness Metalness Skin Emissive RT3 Velocity.X Velocity.Y FOG R8G8B8A8(sRGB) R10G10B10A2 R8G8B8A8 Velocity符号 R10G10B10A2 (X:1bit Y:1bit) 33 / 127

Gバッファのレイアウト RT3 Velocity.X Velocity.Y FOG Velocity符号 R10G10B10A2 (X:1bit Y:1bit) 速度バッファのR10G10B10A2へのエンコード 0.0付近が高精度になるように精度分布させる ⇒後述のTemporal Antialiasingで1ピクセル以下の精度が求められる なるべく数値情報を多く持てるように符号部を分離 ⇒高速な動きにも少しでも追従できるように ⇒数値部10bitと符号部1bitで実質 11bit 表現 1bit + 10bit 34 / 127

Gバッファのレイアウト
RT3 Velocity.X

Velocity.Y

Velocity符号 R10G10B10A2
(X:1bit Y:1bit)

FOG

速度バッファのR10G10B10A2へのエンコード
エンコード - 擬似コード例
float4 encodeVelocity(float2 velocity, float fog)
{
// per-pixelに丸める
float2 v = velocity * float2(1920/2,1080/2) * (VELOCITY_FRACTION_SCALE/1024.0);
// 長さがオーバーフローCLAMPされて方向が歪む問題への対策。
// 表現可能な長さ1.0を超える場合は長さをCLAMPする
v *= rcp( max( max(1.0, abs(v.x)), abs(v.y) ) ); // max3
// 精度分布を0付近を高精度にする
float3 result;
result.xy = sqrt( abs(v.xy) ); // sqrtは近似最適化できる
result.z = fog;

}

// フラグ化実装をわかりやすく書いた場合（実際は最適化するべき）
// GBufferの帯域次第ではこの程度の分岐処理は隠蔽される可能性もある。
int signBit = 0;
if( v.x < 0 ) signBit |= 2;
if( v.y > 0 ) signBit |= 1;
// Yは上下反転
result.w = float(signBit) * (1.0/3.0) + 0.01; // 誤差分丸め
return result;

デコード - 擬似コード例
float2 decodeVelocity(in float4 velocityFog)
{
// フラグ化実装をわかりやすく書いた場合（実際は最適化するべき）
int
signBit = int(velocityFog.w * 3.01);
// 誤差分丸め
float2 s;
s.x = (signBit & 2) ? -1.0 : +1.0;
s.y = (signBit & 1) ? -1.0 : +1.0;
}

return velocityFog.xy * velocityFog.xy * 1024.0f/VELOCITY_FRACTION_SCALE * s;

TemporalAAで高精度なサブピクセル追従
モーションブラーで高速オブジェクトの追従
1080p環境下で比較的実用範囲で両立できた

35 / 127

Gバッファの出力結果例 Albedo Normal Roughness Metalness AO Velocity 36 / 127

ディファードGバッファで半透明への対処 Gバッファ内は半透明が利用不可。 ⇒パンチ抜き半透明表現で対応 単純フェードin/out程度なら比較的問題ない。 後述のTemporalAAで、ある程度平滑化される。 static const float ATV = 0.030 * 2.0; // 1 / 16.5 // static const float ATV = 0.03125 * 2.0; // 1 / 16 static const float ALPHA_THRESHOLD[4 * 4] = { ATV * 1.0, ATV * 7.0, ATV * 16.0, ATV * 14.0, ATV * 11.0, ATV * 9.0, ATV * 2.0, ATV * 8.0, ATV * 5.0, ATV * 3.0, ATV * 12.0, ATV * 10.0, ATV * 15.0, ATV * 13.0, ATV * 6.0, ATV * 4.0, }; アルファテスト併用時 : 輪郭部分とディザが干渉してしまう ⇒エッジ部分のディザのみを取り除く輪郭補正を実装 37 / 127

エッジ補正 あり

エッジ補正 なし

アルファテストエッジのみディザ感を抑制
void
{

}

punchOutMask( in float2 spos, in float alpha, float alphaMaterial,
in float mask, in float cut )
int2 ipos
= int2(spos) & 3;
int
sampleIndex = madd_int24( ipos.y, 4, ipos.x ); // y * 4 + x [1-cycle]
float threshold
= ALPHA_THRESHOLD[sampleIndex];
float amask
= threshold * mask;
if( ((alpha - cut) <= (amask - amask * cut)) || ( alphaMaterial < threshold ) ){
discard;
}

void
{

}

punchOut( in float2 spos, in float alpha )
int2 ipos
= int2(spos) & 3;
int
sampleIndex = madd_int24( ipos.y, 4, ipos.x );
if( alpha < ALPHA_THRESHOLD[sampleIndex]){
discard;
}

// y * 4 + x

[1-cycle]

⇒アーティストで調整可能にパラメーター化

38 / 127

Clustered Shading -光源 の効率的なカリング- Clustered Deferred and Forward Shading (2012) Ola Olsson , Markus Billeter and Ulf Assarsson [Clustered12] A 2.5D Culling for Foward+ (SIGGRAPH ASIA 2012) Takahiro Harada [Harada12] ⇒高速化の一環で導入。 奥行き方向に重なったときに効果的 ※今回は元データの相性との都合でForward+自体は対応を見送った 39 / 127

次世代への画質向上と新しいワークフロー 物理ベースレンダリング 40 / 127

物理ベースレンダリングの導入 DirectX11世代では標準的に採用される マテリアル質感の向上 リアリティー 品質の底上げ効果 シェーダーをシンプルに 簡略化 一貫性 異なる環境光下で安定した結果 41 / 127

物理ベースレンダリングの導入 長所：シェーダーをシンプルにできる 代表的なBRDFモデルを採用することで単一化可能 CookTorrance OrenNayar Specular Diffuse 個別に専用に書いていたシェーダーから脱却できる ※但し、異方性を持った材質など特殊なものは別途考慮が必要 42 / 127

シェーダーのシンプル化によるメリット バリエーション大量生成の回避 プログラマーの開発コストの低減 GPU実行効率の向上 調整パラメーターの簡略化 (ラフネス＆メタルネス) 43 / 127

3Dモデルのリファイン作業 プログラム側のシェーダーメンテコストは低減できる …とはいえ3DモデルはPSP当時そのままでは使えない 3Dデーター構造がPSP世代と全く異なる！！ 44 / 127

必要なテクスチャ情報の違い PSP世代 DX11世代 カラーマップ Texture ○ － スフィアマップ Texture ○ － Albedo Texture － ○ 法線 Texture － ○ ラフネス Texture － ○ メタルネス Texture － ○ AO Texture － ○ IBL CubeTexture － ○ 必要な情報が全く違う!! アーキテクチャの違い ライティングモデル シェーダー有り無し 何もかもが別物！！ 45 / 127

必要なテクスチャ情報の違い PSP世代 DX11世代 カラーマップ Texture ○ － スフィアマップ Texture ○ － Albedo Texture － ○ 法線 Texture － ○ ラフネス Texture － ○ メタルネス Texture － ○ AO Texture － ○ IBL CubeTexture － ○ 唯一再利用できそうなのは… カラー…マッ..プ??? …しかしカラーマップと Albedoは概念が異なる 46 / 127

カラーマップとAlbedo ColorMap Texture 見た目の色味でコントロール 物理的に正確ではない Albedo = 0.7 入射光 100% 出射光 70% アーティストの感性で調整していた Albedo Texture Albedoの概念 外部からの入射光に対する反射光の比。反射能（はんしゃのう）とも呼ぶ。 物理的に反射率としての数値的意味がある。(0%～100% の 百分率で表現) 物質によって決まっている値。主に計測によって知ることができる。 47 / 127

カラーマップとAlbedo Albedoに陰影を含めてはならない 陰影をつけても暗くなるわけではなく『黒い材質』になるだけ。 陰影情報が取り払われたフラットなデーターが必要。 例えば… 「Albedo = 塗装色」と考えると影を塗ってはいけないことが分かり易い 本来はカラーチャートとグレーシートを使って 計測後の輝度やホワイトバランスの補正が必要。 ※Albedoは0.0～1.0の表現で持てるため Gバッファ形式 R8G8B8A8 で十分使えた 48 / 127

Albedoの見た目の例 Albedoには陰影を含めずに反射率を示す値として持つ 49 / 127

原作データーの再利用 3Dモデルデーターの制作方針 プレイヤーキャラクターや主要オブジェクトはリメイク 物理ベースレンダリングに使用するフルクオリティ 当時ムービーレンダリング向けに使用されていた高品質モデル サブキャラクターと背景はPSPのジオメトリを再利用 カラーマップをAlbedoに再利用 ＆ 辻褄が合うように調整 物理ベースパラメーターや法線マップは追加 テクスチャは4倍解像度(縦4倍 x 横4倍 = 16倍のピクセル数)へ変換 明らかに品質が足りないと判断されるジオメトリはリファインの対象へ 50 / 127

原作データーの再利用 グラフィックの演出指針 照明モデル刷新はPSP版原作スタッフによる再調整 HDR化によって照明の見た目が大きく変わってしまう ⇒光の当たり方も距離減衰も物理ベースレンダリングによって本質が変化 ⇒アーティスティックな演出とリアリティあるライティング 60fpsか？30fpsか？ 性能的問題よりも原作システム構造上の制限のほうが大きかった 全実装を60fpsに置き換えるには多くの期間が必要だった。 ⇒60fps化は惜しみつつ見送ったが30fps分の処理余力全てを品質向上に回した 51 / 127

原作データーの再利用 パラメーター再調整後の3Dモデル Albedo / Normal / AO roughness / metalness / emissive ジオメトリがPSPのままでもパラメーターがしっかり入っていると質感が良い。 52 / 127

3Dデータのサイズ規模と容量比較 携帯機PSP ⇒ ハイエンドPS4/XboxOne据置 プレイヤーキャラクター「エース」の 例 PSP版 TRIANGLE HD版 1,074 tri 41,333 tri 容量比 38.4 x MODEL 57 KB 5 MB 89.8 x TEXTURE 76 KB 23 MB 309.8 x 133 KB 28 MB 200 x TOTAL 全体サイズは200倍に大幅に増大 53 / 127

3Dデータのサイズ規模と容量比較 1,074 triangle PSP版 Color 41,333 triangle HD版 Albedo / Normal / Roughness Metalness / AO 54 / 127

55 / 127

56 / 127

57 / 127

物理ベースレンダリング導入の概要 スペキュラー項 Specular CookTorrance (GGX + Smith + ShrickFresnel) Microfacet Models for Refraction through Rough Surfaces [Walter07] (実際の計測結果) Chrome GGX Beckmann Physically-Based Shading at Disney [Disney12] GGXはBlinn Phongよりもテールが長い 現実の計測結果に一層近い 演算量と品質のバランスが良い もう少しテールが長いとより理想的。。。 58 / 127

物理ベースレンダリング導入の概要 ディフューズ項 Diffuse OrenNayar Lambert 高速化/処理負荷のために後に変更。やむをえず。。。。(´；ω；｀) ⇒OrenNayarとLambertの見た目の差異が大きくないため今回は妥協。 ※ Wikipedia “オーレン・ネイヤー反射” より引用 OrenNayarはラフネス1.0以上のスーパーラフ(Super Rough)が表現でき、物理現象に近い特性。 59 / 127

OrenNayer vs Lambert
OrenNayer演算量
float3 Lighting_OrenNayar(
in const float3 N,
in const float3 L,
in const float3 V,
in const float3 albedo,
in const float
roughness
){
// tの計算
float
NoL = saturate( dot(N, L) );
float
NoV = saturate( dot(N, V) );
float
orenNayarS = saturate( dot(L, V) ) - NoL * NoV;
float
orenNayarT = rcp(max(NoL, NoV) + 0.00001);
orenNayarT = (orenNayarS < 0.0) ? 1.0 : orenNayarT;
float
st = orenNayarS * orenNayarT;

}

// ラフネスが 0.0～1.0になるように限定すると高速近似可能
// 参照 : A tiny improvement of Oren-Nayar reflectance model
float
A = rcp((PI * 0.5 - 2.0/3.0) * roughness + PI);
float
B = roughness * A;
return albedo * NoL * (A + B * st);

Lambert演算量
float3 Lighting_Lambert(
in const float3 N,
in const float3 L,
in const float3 albedo
){
const float KD = 1.0 / PI; // 半球積分
return albedo * max( 0, dot(N, L) ) * KD;
}

エネルギー保存

背に腹は代えられない…!!
ライト単体だけで考えるとOrenNayerでも十分に
テクスチャフェッチに隠れる。
Gバッファへのアクセスで隠蔽できる。
しかし複数光源で何回もループすると
ALUサイクル数が地味に ボトルネックになる。

60 / 127

パラメーター表現 – roughness / meatlness Specular Workflow AlbedoMap / SpecularMap Albedo/Specular両方をカラーで保持 スペキュラーを金属色で持つ 金属の場合はAlbedoは「黒」にする。 金属色が見やすくペイント時に直感的 後者 を採 Metalness Workflow AlbedoMap / MetalnessMap 用 !! Metalnessをグレースケールで保持 金属色はAlbedoを反映 テクスチャ容量が節約できる＆高速。 【参考資料】Marmoset Toolbag 2 チュートリアルより http://www.marmoset.co/toolbag/learn/pbr-practice 61 / 127

• http://www.marmoset.co/toolbag/learn/pbr-practice

点光源の半径表現 ラフネスを補正することで近似表現 Real Shading in Unreal Engine 4 (SIGGRAPH 2013) [UE4SIG13] ラフネスでスペキュラーの鋭さを弱くして 擬似的にエリアライトを表現 62 / 127

エネルギー保存 Energy Conservation 入射光の総和 ＝ 出射光の総和 Diffuse ○% + Specular ○% = 100% Diffuse + Specular は光源のエネルギーを超えない 収束(Roughness=0.0)と拡散(Roughness=1.0)でも輝度エネルギーの総和は一致する 今回の物理ベースシェーダーでの実際の描画結果 GGX NDF(Normal Distribution Function) ではエネルギー保存を考慮した式になっている。 63 / 127

Specular Occlusion (SO) AOでの遮蔽でスペキュラー成分も遮蔽される。 CEDEC 2011 レンダリストのための物理ベースレンダリング –実装編– tri-Ace 五反田 義治氏 講演 Real-time Physically Based Rendering – Implementation [GOTANDA2011] AO成分がある箇所でも光ってしまう問題を解決可能 最適化版が演算も高速で実用的 64 / 127

Image Based Lighting Cubemapのミップレベルにラフネスの結果を畳み込む方式 今回はGGXを採用しているため GGXブラーカーネルを使った専用のGGXCubemap変換ツールを社内で作成。 それなりに重い処理のためCPUで行わずに GPU並列コンピューティングで重点サンプリング(Importance Sampling) 静的に事前生成 [GEMS3_IMP] GPU-based Importance Sampling (GPU Gems 3） 超一様分布列 Hammersley Sequence Sampling 65 / 127

AmbientBRDF / EnvironmentBRDF IBLで得られる環境光をスペキュラーにも反映 Practical Implementation of Physically-Based Shading Models at tri-Ace (SIGGRAPH 2010) [GOTANDA2010] Real Shading in Unreal Engine 4 (SIGGRAPH 2013) [UE4SIG13] BRDFを考慮したGI反射適用 Lighting of Killzone: Shadow Fall (Digital Dragons 2013) [Michal13] 3DテクスチャLUTが理想だったが 高速化のために2Dテクスチャに格納した U方向 cosθview (0.0～1.0) V方向 ラフネス値 (0.0～1.0) Uneral Engine 4 / Killzone Shadow Fall と同じ手法 視線方向に依存しないように N オフラインで生成した =V 66 / 127

AmbientBRDF / EnvironmentBRDF Real Shading in Unreal Engine 4 (SIGGRAPH2013) [UE4SIG13] からの引用画像 A B C A B C 重点サンプリングされた結果(Reference) GGXブラー + AmbientBRDF BのAmbientBRDFを2DLUT高速化近似 今回実装したテスト結果 @ 67 / 127

Image Based Lighting GGX ブラーキューブマップ + AmbientBRDF テスト結果 Roughness Metalness (Metallic) 68 / 127

グローバルIBL / ローカルIBL IBLの映り込みは視差補正して実際のシーンに合わせる [Parallax12] Local Image-based Lighting With Parallax-corrected Cubemap (SIGGRAPH 2012) 69 / 127

グローバルIBL / ローカルIBL IBLの映り込みは視差補正して実際のシーンに合わせる [Parallax12] Local Image-based Lighting With Parallax-corrected Cubemap (SIGGRAPH 2012) 反射ベクトルをキューブサイズとジオメトリ距離とで補正 視差補正あり 視差補正なし 窓の映り込みが一致しない ぴったり一致 !! 70 / 127

ローカルIBL撮影ツール 71 / 127

トーンマッピング Uncharted2方式 Filmic Tonemapping を採用 Uncharted 2: HDR Lighting (GDC 10) [Naughty10] フィルム感光をシミュレートした応答。彩度をともなう発色が良好 ⇒露出自動補正と評価測光を追加実装して利用 72 / 127

物理ベースレンダリング適用結果例 IBLや物理ベースの照明で多種多様な環境光下でも説得力ある結果が得られる 73 / 127

クオリティーと実行速度の両立 影表現の最適化 74 / 127

影 –Shadow平行投影 + 3カスケード(1024x1024x3)を採用 XboxOne高速化のトレードオフで決定 ・1024x1024のResolve性能が良好 やはり・・・ Killzone2の手法が安定要素多く手堅かった ⇒テクセルのチラつきを無くすことが出来る ⇒視線方向の特異点がなく安定 ⇒平行移動だけでテクセルを再利用可能 The Rendering Technology of Killzone 2 [Michal09] 【参考】ShaderX6 “Stable rendering of cascaded shadow maps” リアルタイムイベントシーン用に1段目のみ高解像度化 ⇒2048x2048に切り替え 75 / 127

影 –Shadow- Secrets of CryENGINE 3 Graphics Technology, CRYTEK [CRYTEKSG11] 高速化のためにサンプリングパターンを改良 実行サイクルを極小化 Texture.SampleCmp(sampler, uv, int2(offsetX, offsetY)); オフセット指定でサンプリングポイントを変えることでレジスタ消費を節約。 GCNアーキテクチャ(PS4 / XboxOne)にとって最適化効果が高い。 中景以降(2段目以降) はTemporalサンプリングを使用 ⇒Temporal Samplingについては後述 最適化したPCFテクセルサンプリングパターン 6 sample point 76 / 127

影 –Shadow半透明なオブジェクト影への対応 シャドウ生成時に透明度を反映 ⇒GBufferと同じくパンチ抜きで実装 Stochastic Renderingの簡易版 Stochastic Shadowmaps ・ディザノイズでレンダリングピクセルを散らす ・PCFで遮蔽計算と平滑化効果。ノイズを消せる ・4x4ディザパターンで実装 色つきシャドウにも拡張可能 Colored Stochastic Shadow Maps 【検証GIFアニメーション】 フェードアウトする軍用クアール (影が滑らかにフェードアウト) (NVIDIA) [McGuire11CSSM] 77 / 127

影 –Screen Space Raytraced Shadow全方位シャドウはScreen Space Raytraced Shadowで実装 適用範囲 エフェクトなどの動的光源での影 焚き火などの一部の演出効果 Gバッファのみで実装できる キューブマップ全方位シャドウより軽量 決して軽い処理ではない 階層Z(Hi-Z)を生成しレイトレース高速化 情報がない遮蔽の向こう側は背後は擬似的 ⇒しかし思っていたよりも意外と違和感が少なかった 78 / 127

影 –Screen Space Raytraced Shadow- 79 / 127

影 –Screen Space Raytraced Shadow全方位に放射状に広がる影 80 / 127

影 –Screen Space Raytraced ShadowClustered Shadingでのカリング効果が高かった 照明計算と同時に行うと デプスフェッチしながらのレイトラバースが 複雑化でシェーダー最適化を阻害してしまう。 照明直後ディファード解決前の別パスで ライト累積バッファから照明計算の引き算で 照明を同輝度で±0相殺して影遮蔽生成 負の輝度を持つライト …!! Deferred Resolve前であれば… 一度当てたライトを無かったことに出来る 81 / 127

処理負荷とグラフィック品質への対策 TEMPORAL SUPER SAMPLING 82 / 127

処理負荷の増大 グラフィックの品質向上に比例してGPU負荷が増大 GPU処理可能時間は有限 (60fps:約16.6ms / 30fps:約33.3ms) 高解像度化 シェーダー高度化 レイトレーシング 情報量増加 表現力向上 ラスタライズからサンプリングへ 表現の進歩により負荷が顕著に表面化 83 / 127

処理負荷の増大 - CPUで起きたパラダイムシフトの例 - CPUの場合はシングルコアからマルチコアへ 1つのCPUコアだけでは性能向上に限界があった 複数コアにして横方向への拡張でトータル性能を向上 マルチコアでは1つあたりの負荷が低い 84 / 127

Temporal Super Sampling GPUの描画負荷を似た考え方で分散する手法 描画を1-Frameで全てを描画せず複数Frameに負荷分散 本作では複数の用途に活用し品質向上に大きく寄与 ⇒ アンチエイリアシング高速化 / 高品質化 ⇒ シャドウ 高速化 ⇒ SSAO 高速化 / 高画質化 PIXEL ⇒ ローカルリフレクション (Screen Space Real-time Reflection) 85 / 127

アンチエイリアシングの選択 当初は開発中期まではSMAAを採用していた SMAA: Enhanced Subpixel Morphological Antialiasing [JIMENEZ2012_SMAA] 長所 FXAAはぼやけるがSMAAはシャープな結果 短所 FXAAよりも処理負荷が高い ⇒破綻ケースが少ないため安定 ⇒煉瓦の壁のエッジなど類似色になる境界線は効きが弱い ⇒判定精度を上げると解決する。しかし…さらに重くなる… 86 / 127

アンチエイリアシングの選択 処理負荷の最適化の過程でAAを高速化したかった アンチエイリアシングは常時負荷として計上されるフィルター 軽くすることでゲーム全体を一定量高速化できる期待 AGAA FXAA 最近では Aggregate G-Buffer Antialiasing (NVIDIA I3D15) なども登場 SMAA MLAA MSAA etc… MSAAは早い段階で選択肢から除外 性能面でSMAAより速くなることは無い。 87 / 127

救世主!! Temporal Antialiasing Temporal Super Sampling の考え方をAAに応用 AA無効の複数フレームからサブピクセル情報を収集。 エッジのピクセルの状態を蓄積して高品質な1-frameを構築。 frame frame frame frame frame 高品質 AA frame …は言い過ぎか？ 1ピクセル未満のサブピクセルを蓄積するためMSAA並に綺麗!! 88 / 127

Temporal Antialiasing 投影後のスクリーン座標にJitterオフセットを加算 ⇒サブピクセル分ずらして振動させることで情報量を増やすアイデア High Quality Temporal Supersampling / EPIC GAMES / SIGGRAPH2014 [BrianKaris] サンプリングパターンはMSAAでも採用されるHalton数列 Wikipedia “Halton sequence” より 89 / 127

Temporal Antialiasing 速度バッファで1フレーム前のピクセルを拾って再利用 Accelerating Real-Time Shading with Reverse Reprojection Caching [Nehab2007ARS] -velocity map - 速度バッファ 90 / 127

Temporal Antialiasing 速度バッファで1フレーム前のピクセルを拾って再利用 Accelerating Real-Time Shading with Reverse Reprojection Caching [Nehab2007ARS] 速度バッファの逆方向のピクセルを拾う 1フレーム前にあった場所の情報を拾うことができる 1フレーム前 現在 AAには1ピクセル未満の値が表現できる精度が必要。 別でのオブジェクト遮蔽されていた場合は再利用しない デプス値の差が一定以上大きければ棄却する if 判定 画面外は遮蔽と同じく棄却対象 再利用できる部分のみを選別できる 破棄 91 / 127

Temporal Antialiasing SMAA 1TX 今回の実装のベースになっている技法 (SMAAのテンポラル版) TL TR BL BR M 対象の中心ピクセル 2x2ピクセルの中点をバイリニアサンプルする4ピクセル平均 【この手法のポイント】 1フレーム前の情報を合成するときに 現在の色で拘束するのではなく 隣接ピクセルの値で可動許容範囲を作っている N M N 1フレーム前の色をこのあそび領域範囲でクランプしてから合成 色が元の色から逸脱・破綻することがなくなる CryENGINE 3 Graphics Gems / Crytek [Sousa13] 92 / 127

Temporal Antialiasing 改 – customized version 今回のためにサンプリングポイントを独自カスタム TL BL M TR BR SMAA 1TX 長所 短所 T L M R B TemopralAA改 customized version SMAA 1TXよりもピクセルの安定化効果(チラつき低減作用)が強い 参照範囲が広くなるため若干鮮明さが弱くなる。 テクセルフェッチ命令をSampleからLoadに変更できることで高速化も 93 / 127

HDRでの高輝度スペキュラーの問題 HDR最大の天敵『スペキュラーエイリアシング』 スペキュラー計算の結果、ハイライトが鋭い高輝度に。 鋭さが1ピクセル未満のサイズのハイライトになった場合 普通のラスタライズレンダリングではチカチカとピクセルチラつきになる。 高光沢の表面や遠景で起きやすい。 見た目がジャギやモアレ現象にも似ている。 スペキュラー エイリアシング発生 対策後 94 / 127

Temporal Antialiasing 比較 No AA SMAA TemporalAA改 スペキュラーエイリアシングの抑制効果 TemporalAA改ではガタガタ感が大幅に低減 (但し若干高周波ディテールが弱まる) 95 / 127

Temporal Antialiasing –時間軸方向のチラつきを比較- 96 / 127

アンチエイリアシング手法の比較 手法 メモリ GBuffer 描画 輪郭 遠景 時間軸 調整 負荷 負荷 品質 品質 安定 難度 MSAA × × △ ◎ ◎ ◎ ◎ FXAA ◎ ◎ ◎ △ △ × ◎ MLAA ◎ ◎ ○ ○ ○ × ◎ SMAA ◎ ◎ △ ◎ ○ △ ○ TemporalAA ◎ ◎ ◎ ◎ ◎ ◎ △ マルチサンプルAA 消費 速度 TemporalAA>SMAA Temporal !! 品質 TemporalAA>SMAA Temporal系のSMAA 1TX / TXAAも同様に時間軸方法の安定性が強力。 フレーム単体のAAよりTemporal方式のほうがチラつきが少ない。 97 / 127

テンポラルのすすめ 処理負荷を分散可能 軽い負荷で重い処理を実行できる。 1ランク、2ランク上の表現を導入できる可能性。広い応用範囲。 非常に高いアンチエイリアシング効果 16xAAに匹敵する品質をFXAA並の軽い負荷で。 時間軸方向のちらつきの高い抑制効果。但し調整にクセがある。 HDR時代スペキュラーエイリアシングへの突破口 高輝度スペキュラーのちらつきとの決別。ひとつの選択肢に。 導入で劇的な改善効果が見込める。但し鋭いハイライトで少しディテールが潰れる スペキュラーAAは他の手法も多数 (VMF / LEAN / CLEAN / Toksvig etc...) 98 / 127

HDRとLDRの共演 / PSP版の表現との共存 光学フィルターと特殊描画パス 99 / 127

HDR光学エフェクトをLDR合成 レンズエフェクトは別のHDRバッファに蓄積しておき最終段で合成 ⇒レンズ内で発生する現象は一番手前レイヤーで適用されている必要あり 後 HDRレンズエフェクト ・・・・・・ 前 LDR VFX 今回VFXはLDRで移植になったためLDR空間の後段パスにVFXが存在。 ⇒VFX後にレンズエフェクトを合成。 ⇒別枠で後合成するためトーンマッピングを考慮して輝度トーン補正を適用 100 / 127

HDRとLDR共存を考慮した描画フロー TemporalAAのJitterをGBuffer生成時に実装した場合 最終イメージ出力までにTemporalAAで揺れを解決する必要がある。 ⇒途中パスで解決前のバッファを使用したときは別途解決が必要。 ⇒今回はHDR/LDR混在の特殊環境で定石となる描画順は踏めず適用箇所が本来とは異なり複数必要だった。 今作のHDR/LDR混在の特殊描画の流れ 光学系 揺れ解決前に参照されるために LDR後段パス合成のために 別途適用 残光 縮小バッファに別途解決 光学系 TAA グレア系は本来のHDRで処理するが LDRエフェクトが描き終わった後の 最前面レイヤーに必要だった トーン マッピング レンズフレア 光学系 GBuffer 生成 (MRT) グレア HDR SSAO 光源 IBL 天球 輝度 抽出 トーン マッピング TAA SSR DOF前に解決が必須 LDR VFX (半透明) 光学系 DOF モーション ブラー TAA HUD LDRエフェクトのエッジ解決 なぜローカルリフレクションの位置がここに？（後述） 101 / 127

HDRとLDR共存を考慮した描画フロー TemporalAAの「もうひとつのメリット」 ⇒TemporalAA(TAA)はAA効果以外にTemporal Super Samplingで安定化が望める ⇒当初は高速化の目的で選択したが、シーン全体の画質向上に絶大な効果があった 今作のHDR/LDR混在の特殊描画の流れ 光学系 揺れ解決前に参照されるために LDR後段パス合成のために 別途適用 残光 縮小バッファに別途解決 光学系 TAA グレア系は本来のHDRで処理するが LDRエフェクトが描き終わった後の 最前面レイヤーに必要だった トーン マッピング レンズフレア 光学系 GBuffer 生成 (MRT) グレア HDR SSAO 光源 IBL 天球 輝度 抽出 トーン マッピング TAA SSR DOF前に解決が必須 LDR VFX (半透明) 光学系 DOF モーション ブラー TAA HUD LDRエフェクトのエッジ解決 なぜローカルリフレクションの位置がここに？（後述） 102 / 127

光学的表現とLDRとの共存 ポストエフェクトフィルター 103 / 127

零式HDのポストエフェクトフィルター ポストエフェクト描画負荷は全体の約50% ⇒テクスチャ解像度を上げているとはいえ 基本的にモデルデーター素材はPSP当時のもの。 品質向上のために負荷でポストエフェクトが占める割合を高くした。 HDR/LDR混在の特殊な構成 HDRフィルター/LDRフィルター 共存矛盾の問題が発生!! 104 / 127

矛盾を起こさない描画順序の検討 本来は全てHDR空間で行いたいがLDR VFXが存在。 エフェクト前と後で掛けるフィルターを吟味…!! HDR空間で実行 Bloom アナモルフィックレンズフレア レンズフレア 残光 SSAO LDR空間で実行 PSP互換Bloom LDR !? 被写界深度 !? ローカルリフレクション モーションブラー !? !? カラートーンカーブ補正 105 / 127

矛盾を起こさない描画順序の検討 これら3つのフィルターは少なくともVFXを含めた結果であるべき ⇒VFXの表現と連携するためにLDR化したフィルターが必要になった。 ⇒LDRのままでは見た目が退化するためHDR補正を掛けて適用 HDR空間で実行 Bloom アナモルフィックレンズフレア レンズフレア 残光 SSAO LDR空間で実行 PSP互換Bloom LDR !? 被写界深度 !? ローカルリフレクション モーションブラー !? !? カラートーンカーブ補正 106 / 127

HDR補正の着想点 当時アーティストによって綿密に調整されていたVFX ⇒見た目での調整ではあるものの、ベストだと判断された結果によるもの ⇒光や炎、魔法表現が美しいFINAL FANTASYの効果美術 言い換えると… トーンマッピング後の結果をアーティストが自身の感性で描き上げたに等しい 107 / 127

HDR補正の着想点 逆トーンマッピング (Inverse Tonemapping) ⇒HDR空間のものをLDR空間に落とし込む手法がトーンマッピング ⇒(必ずしも正確ではないが) LDR空間から逆算して本来のHDR空間輝度を推定できないか？ 物理ベースと異なりad-hocな対応ではあるものの 全く補正を掛けないときよりも見た目は大きく向上 前世代までの明るい部分を抽出してグレアにする手法に近い。 トーンマッピングを考慮して、もう少し厳密に行なったバージョン。 HDR HDR輝度のVFX ？？？ 逆トーンマッピング VFX HDR空間 LDR空間 HDR空間 LDR 1.0 1.0 1.0 0.0 0.0 0.0 ？ 108 / 127

HDRでBloomの問題点と解決 HDR縮小バッファでは輝度差でバイリニアフィルタ特有の 四角い拡大アーティファクトがより顕著に目立つように アンチ縮小バッファアーティファクト (CEDEC 2009) [Kawase09] 通常描画時 アーティファクト対策後 実際の実装と対策の検証比較 品質的に問題ないレベルに改善 非常に良い手法だった 109 / 127

残光フィルター After grow 感覚的 / 経験則的に眩しさを感じさせる効果 高輝度で残像。簡易的な網膜の残像シミュレート表現を行う。 ⇒プルキンエ (プルキニェ) 現象 (Purkinje effect) 桿体細胞の影響で青色系にカラー変化を起こすフェードアウト 110 / 127

SSAO –Screen Space Ambient OcclusionAOマップだけでは表現できない動的な遮蔽項の生成 Scalable Ambient Obscurance (HPG12) NVIDIA [McGuire12SAO] の手法をベースに実装 高速化のために前述の Temporal Super Sampling 拡張実装 1フレームに1サンプルしか 遮蔽判定フェッチしていない GPU負荷1ms以下で非常に高速 Temporal化でノイズが抑えられた 111 / 127

被写界深度 映像のフォーカス / ピンぼけ表現 絞り形状を伴うぼけ表現。旧来のガウス暈しと比較すると空気感が違って見える LDR空間で適用が必須条件 ⇒前述のHDR補正を行った 高輝度成分に絞り形状が現れる 112 / 127

被写界深度 –ロックオンDOF対象物をロックオン(注視)したときにDOF 新規導入 ・ゲーム中での記号的意味合い。注視感・臨場感が増す ・カメラがズームするときにフォーカスが連動する ・ F値、レンズ焦点距離など厳密なレンズシミュレートは今回は都合上見送った 113 / 127

モーションブラー 当初はシーンに速度感/躍動感を与えるために導入 フレーム補間効果で、30fps動作での動きの滑らかさ向上 リアリティを感じさせる相乗効果が得られた 114 / 127

モーションブラー -時間軸方向の補間- フレーム間の中間情報の内挿で情報量が増加 時間 仮想的にフレームレートが増加する カクカク感が大幅に低減され、動きへの目線追従効果も。 今作では 2pass 36tap サンプルのブラー生成 115 / 127

モーションブラー 全方位探索方式と異なりサンプリング負荷が低いアルゴリズム A Reconstruction Filter for Plausible Motion Blur (NVIDIA) [McGuire12Blur] 周辺の速度最大値を生成 今回は独自にカスタム ・64x64タイルで適用 ・解像度30x16の速度バッファ ・ブロックアーティファクト低減 高いL2キャッシュヒット率で高速。広範囲のブラーを可能に。 Ryseでの実用事例も参考になった。 CryENGINE 3 Graphics Gems [Sousa13] 116 / 127

モーションブラー HDR補正 HDRを考慮したLDR空間でのHDR補正つきブラー生成 参考比較画像 HDR補正はDOFにも適用 補正でLDR VFXもHDRのような振る舞いをする 117 / 127

モーションブラー HDR補正 VFXもHDR補正で輝度応答を近似 118 / 127

ローカルリフレクション 別名: Screen Space Ray-traced Reflections (SSRR) GBufferで反射計算、デプスバッファをレイマーチ Taking Killzone Shadow Fall Image Quality Into The Next Generation [Michal14] スクリーン空間で実行するため専用の構造が必要ない ラフネスを考慮したブラーでリフレクションにラフネス反映 高速化Tips ・HiZを生成してなるべく低解像度＆広いステップでレイマーチ開始 ・探索を早めの距離で打ち切る (打ち切っても遠景ではさほど問題にならない) ・Jitterでランダムサンプリング & Temporal Super Sampling で安定化 119 / 127

ローカルリフレクション OFF 120 / 127

ローカルリフレクション ON 121 / 127

ローカルリフレクション OFF 122 / 127

ローカルリフレクション ON 123 / 127

ローカルリフレクション -GIリフレクション相互反射の発生 1次反射 通常レンダリング結果 リフレクション成分のみ テスト表示 2次反射 3次反射 Specular 1フレーム前の結果をリプロジェクションでリフレクションソースとして使う 成分 ⇒２次反射・３次反射…とフィードバック繰り返し反射するためGIを近似できる 124 / 127

ローカルリフレクション –適用タイミングの変更今回は本来の適用タイミングで適用出来ない問題があった… 本来のワークフロー Specular 光源 Diffuse SSR IBL IBL 光源 SSSSS Deferred Resolve HDR トーン マッピング LDR ローカルリフレクションとIBLとをブレンドしてスペキュラー項生成 今作の特殊フロー Specular Diffuse 光源 光源 SSR IBL IBL SSSSS Deferred Resolve HDR トーン マッピング LDR SSR トーンマッピングも全て終わった事後に合成しなければならない。IBLとの競合は避けられないが 輝度はHDR補正で解決。合成フェーズは各成分を分離計算するため複雑。 125 / 127

肌の表現 表面下散乱 なし 表面下散乱 あり 126 / 127

Screen Space Sub Surface Scattering ポストエフェクトで表面下散乱を表現 Screen-Space Perceptual Rendering of Human Skin [JIMENEZ2010_GPUPRO] シンプルな実装で十分な品質 ディフューズ成分のみにブラー スペキュラーとディフューズは分離 スキン部分にマスクで局所適用 ライト累積バッファを Diffuse / Specular 別々に処理 ⇒ 合成前にSSSSSを適用。 127 / 127

レフ照明 (通称 : キャッチライト, 女優ライト) 光量の不足や強い照明がキャラクターにあたった場合 ⇒凹凸によってコントラストが非常に強くなる。 ⇒角度によっては見た目が怖い場合もあり得る（真下からの強いライトなど） ポートレート写真ではレフ照明で陰影を和らげる撮影手法がとられる いかなる環境下でもキャラクターが映えるように補助的に適用 複数光源でライトアップすることで 目にハイライトが入る副次的効果 キャラクターが活きて見える やわらかな間接照明1灯ではなく 半径が小さめの光源を３灯 角度を変えて当てる 128 / 127

レフ照明 (通称 : キャッチライト, 女優ライト) レフ照明 なし レフ照明 あり 129 / 127

レフ照明 (通称 : キャッチライト, 女優ライト) レフ照明 なし レフ照明 あり 130 / 127

FINAL FANTASY 零式 HD 開発 まとめ 131 / 127

『FINAL FANTASY 零式 HD』開発を経て 原作の良さと新しい表現の両立に成功 工夫次第で現行の技術トレンドを織り込むことが出来る!! 新しいHD化の可能性が見えた 単なるHDリマスターの領域を超えた映像表現が不可能ではなかった!! 当初の想定よりも多くの見識を得た 急な方針転換で開発は大変だったが大英断だった!! 綺麗になった !! 素直に喜ばしい SQUARE ENIX FINAL FANTASY 零式HD 開発チームと ヘキサドライブの連携体制によって双方に技術の蓄積ができた。 132 / 127

『FINAL FANTASY 零式 HD』開発を経て 物理ベースレンダリングでの留意点/課題 輝度単位の統一はきわめて重要 !! (照明 / IBL / エミッシブ の輝度) ⇒いくら破綻しないという物理ベースでも基準が異なると簡単に破綻。 今回はスケールをPSPにあわせてLDR両立の別単位を作る必要があった HDRスペキュラーエイリアシングをどう対処するか？に終始。 ⇒ミップマップ＆異方性フィルタ でモアレを除去しても… アンチエイリアシングで輪郭のジャギー(エイリアシング)を除去しても… スペキュラーエイリアシングが全てを台無しにしてしまう・・・!!! 今回は Temporal Antialiasing でこの問題を複合的に解決した 133 / 127

参考資料 References [Walter07] Microfacet Models for Refraction through Rough Surface (EGSR2007) Bruce Walter, Stephen R. Marschner, Hongsong Li, and Kenneth E. Torrance. [Disney12] Physically-Based Shading at Disney (SIGGARPH 2012) Brent Burley, Walt Disney Animation Studios [RYSE14] Moving to the Next Generation - The Rendering Technology of Ryse (GDC14) Nicolas Schulz, Crytek [UE4SIG13] Real Shading in Unreal Engine 4 (SIGGRAPH 2013) Brian Karis, EPIC GAMES [Michal13] Lighting of Killzone: Shadow Fall (Digital Dragons 2013) Michal Drobot, Guerrilla Games [GOTANDA2011] レンダリストのための物理ベースレンダリング –実装編– Real-time Physically Based Rendering – Implementation (CEDEC 2011) Yoshiharu Gotanda, tri-Ace Inc. [GOTANDA2010] Practical Implementation of Physically-Based Shading Models at tri-Ace (SIGGRAPH 2010) Yoshiharu Gotanda, tri-Ace Inc. [GEMS3_IMP] GPU-based Importance Sampling (GPU Gems 3） Mark Colbert , Jaroslav Krivanek [Parallax12] Local Image-based Lighting With Parallax-corrected Cubemap (SIGGRAPH2012) Sébastien Lagarde, Antoine Zanuttini, DONTNOD Entertainment [Naughty10] Uncharted 2: HDR Lighting (GDC 10) John Hable, Naughty Dog [CRYTEKSG11] Secrets of CryENGINE 3 Graphics Technology (SIGGARPH2011) Tiago Sousa, Nick Kasyan, Nicolas Schulz, CRYTEK [Clustered12] Clustered Deferred and Forward Shading (HPG2012) Ola Olsson , Markus Billeter and Ulf Assarsson [Harada12] A 2.5D Culling for Foward+ (SIGGRAPH ASIA 2012) Takahiro Harada 134 / 127

参考資料 References [Michal09] The Rendering Technology of Killzone 2 (GDC 09) Michal Valient [McGuire11CSSM] Colored Stochastic Shadow Maps (I3D’11) McGuire and Enderton, NVIDIA [JIMENEZ2012_SMAA] SMAA: Enhanced Morphological Antialiasing (2012) Jorge Jimenez and Jose I. Echevarria and Tiago Sousa and Diego Gutierrez [Nehab2007ARS] Accelerating Real-Time Shading with Reverse Reprojection Caching (2007) Diego Nehab, Pedro V. Sander, Jason Lawrence, Natalya Tatarchuk, John R. Isidoro [BrianKaris] High Quality Temporal Supersampling (SIGGRAPH 2014) Brian Karis, EPIC GAMES [Sousa13] CryENGINE 3 Graphics Gems (SIGGRAPH 2013) Tiago Sousa, Crytek [Kawase12] 実践！シネマティックレンズエフェクト (CEDEC 2012) Kawase Masaki, Silliocn Studio [Kawase09] アンチ縮小バッファアーティファクト (CEDEC 2009) Kawase Masaki, Silliocn Studio [McGuire12SAO] Scalable Ambient Obscurance (HPG12) Morgan McGuire, Michael Mara, David Luebke, NVIDIA [McGuire12Blur] A Reconstruction Filter for Plausible Motion Blur (I3D’12) Morgan McGuire, NVIDIA [Michal14] Taking Killzone Shadow Fall Image Quality Into The Next Generation (GDC 2014) Michal Valient, Guerrilla Games [JIMENEZ2010_GPUPRO] Screen-Space Perceptual Rendering of Human Skin (2009) Jorge Jimenez, Veronica Sundstedt, Diego Gutierrez 135 / 127

権利表記 当資料内 「FINAL FANTASY 零式」「FINAL FANTASY 零式 HD」 上記タイトルに関わる全ての掲載画像/権利は 株式会社スクウェア・エニックスに帰属します。 「FINAL FANTASY 零式」： ©2011 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN:TETSUYA NOMURA 「FINAL FANTASY 零式 HD」： ©2011,2015 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN:TETSUYA NOMURA 136 / 127

質疑応答 ? 137 / 127