Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

FINAL FANTASY 零式HDにみる 新しいHDリマスター

122,796 views

Published on

KANSAI CEDEC 2015で講演しました"FINAL FANTASY 零式 HD"の開発事例紹介です。

講演時間の都合上、 どうしてもカットせざるを得なかったページを追加した完全版となっています。

PS4/XboxOne のマルチプラットフォームで同時開発され、PSP の描画フローから今世代機での描画フローへの移行及び、採用された以下の技術を中心に具体例を交えた解説をさせていただきました。
・ディファードレンダリングへの移行
・物理ベースレンダリングの導入
・各種光学フィルタ―の導入と特殊なレンダリングパスの解説
・ローカルリフレクションの採用
フルHD解像度での動作への拘り等、移植の枠を超えた新しいHDリマスターを実現した舞台裏についてプログラマによる解説を交えた内容となっております。

Published in: Technology
  • Be the first to comment

FINAL FANTASY 零式HDにみる 新しいHDリマスター

  1. 1. 1/ 136 FINAL FANTASY 零式HD にみる 新しいHDリマスター 株式会社ヘキサドライブ 開発部 プログラマー 山口 裕也 開発部 チーフテクニカルディレクター 岩崎 順一
  2. 2. 2/ 136 株式会社ヘキサドライブ 設立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.
  3. 3. 3/ 136 プラットフォーム PlayStation Portable 2011年10月27日発売 発売当時 ファミ通 月間/週間ゲームソフト販売ランキング メディアクリエイト 週間ソフトセルスルーランキング 初動売上は47.2万本を記録 FINAL FANTASYの名を冠する作品の中でも アクション性が高い作品 海外でも 評価が高い 発売を望む声が多かった 首位! © 2011 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN : TETSUYA NOMURA
  4. 4. 4/ 136 プラットフォーム PlayStation4 XboxOne 2015年3月19日発売予定 マルチプラットフォーム展開 2プラットフォーム同時開発 各国語 字幕ローカライズ対応 日本語・英語・フランス語・イタリア語・ドイツ語・ スペイン語・韓国語・中国語 (簡体字・繁体字) 原作からのバランス調整・隠し要素追加 グラフィックのリファイン & HDリマスター © 2011,2015 SQUARE ENIX CO., LTD. All Rights Reserved. CHARACTER DESIGN : TETSUYA NOMURA
  5. 5. 5/ 136 開発のワークフロー HD化にあたっての取り組み -世代を越えた “新生”- 携帯機PSPからの3世代とび越えた『HD化』 グラフィックのリファイン & リマスター 新しい世代のグラフィックトレンド導入 物理ベースライティング / DirectX11世代での技術的な挑戦 原作の演出意図を考慮した新描画エンジンと従来の描画エンジンの共存 ポストエフェクトフィルター技術解説 HDRとLDRが混在する特殊条件下での辻褄を合わせたLDR合成
  6. 6. 6/ 136 グラフィック品質向上 フルHD化 1920x1080 対応 物理ベースレンダリング モデルデータのリファイン 光学フィルター 等々… プレイ中の感触の調整 カメラの角度 キャラクターの移動速度 盛り沢山!! ゲーム難易度選択追加 & バランス調整 低難度モード & 高難度モード追加。ユーザーのプレイスタイルを考慮
  7. 7. 7/ 136 開発のワークフロー HD化にあたっての取り組み -世代を越えた “新生”-
  8. 8. 8/ 136 両プラットフォーム共に 1920x1080 (1080p) 同じ体験を可能にするため 最後の最後までパフォーマンス最適化!! PSP PS4 / XboxOne 480 x 272 1920 x 1080
  9. 9. 9/ 136 約17倍の描画面積! 272 480 1080 1920
  10. 10. 10/ 136
  11. 11. 11/ 136
  12. 12. 12/ 136
  13. 13. 13/ 136
  14. 14. 14/ 136 PSP版原作の完全移植 当時の演出や表現を再現して同じ体験を可能にする。 過去のノウハウが活かされたため素早く着実に進めることができた ポストエフェクトフィルターなどプログラムでリッチに。 ⇒グラフィックリソースに影響与えずに品質を上げる 2D系の表示物/メニュー関連は1080p向けにリメイク PSPの描画命令をエミュレーションすることで対応することに決定
  15. 15. 15/ 136
  16. 16. 16/ 136 ほぼ動くようになった段階で追加オーダー入りました…!! PS4/XboxOneに見合った品質に !! 次世代らしい品質に引き上げられないだろうか? SQUARE ENIX × HEXADRIVE 技術のコラボレーション •ヘキサドライブで実装 •プログラム技術で光学エフェクトなど魅力あるビジュアルへ 物理ベースレンダリング •SQUARE ENIXでHD品質を担保 •次世代のソフト開発を経て培ったグラフィック技術 3Dデーターリファイン
  17. 17. 17/ 136 原作には元々無かったものを多数新規追加 シャドウ / ディファードレンダリング / 物理ベースマテリアル 被写界深度 / レンズフレアなど光学エフェクト etc… 描画フローを大幅に刷新 半透明描画を全て後段パスへ移動。天球をHDR化。 背景の多層重ね貼りはGバッファマルチテクスチャへ移動 今作はPSP→DX11世代へのHD化で 世代が違いすぎて描画フローが全くの別物だった
  18. 18. 18/ 136 近年のゲームCGでは標準的なレンダリングフロー シェーディング時に付加情報を得やすい。(速度 / 材質 / マスク情報 etc..) ライティング個数制限がなくなる。(シェーダーの簡略化) メモリ帯域を多く消費する。(Gバッファ生成とそのアクセス) 半透明オブジェクトが使えない。 ⇒半透明不可は致命的なため別途対策が必要。(後描きでForward+など) 長所 短所
  19. 19. 19/ 136 HD版の描画 シャドウ生成 Gバッファ生成 / ディファード HDR光源計算 物理ベースライト トーンマッピング VFXがPSPの状態を維持 !!? PSP版の描画 固定パイプライン カラー描画 プログラマブルシェーダー無し 高度なライティング計算は無い 遠景 (天球 etc…) 背景 (ライティングなし) キャラクタ (ライティングあり) 半透明 (ソート) VFX フィルター HUD (2Dメニュー) シャドウ 生成 Gバッファ 生成 (MRT) 光源計算 IBL 天球 (HDR) トーン マッピング 光学系 フィルター VFX (半透明ソート) フィルター HUD (2Dメニュー) HDR LDR 移行 キャラクタ
  20. 20. 20/ 136 新しい技術検証と新描画フロー刷新 同時進行で検証しながら実装 社内でも過去に類を見ない速度で再構築が進んだ 新生システムが構築された段階で量産開始。 エミュレートを撤廃 直接描画に全変更 物理ベース技術検証 IBL ディファード導入 描画順序再構築 物理ベースシェーダー IBL設置ツール HDR & LDR描画構築 光学フィルター 影 DCCツール拡張検証 1段階目 2段階目 3段階目
  21. 21. 21/ 136 実装を変えてしまうと全く見た目が違うものになってしまう問題 ・フォグ描画を霧以外の用途に活用しているフェイク表現 ・フォグの濃度がゲーム演出にも密接に関連 ・カラールックアップテーブル(CLUT)でのカラー補正機能 ・RGB輝度を抽出して光る演出をしているグレア表現
  22. 22. 22/ 136 物理ベースレンダリング CookTorrance + リニア空間 HDR LDR PSP Lambert & カラー描画 + sRGB空間 PSPからのHD化移植ではPSP当時のレガシーなシステムを 再利用/共存することも避けては通れない事案。 『リメイク』ではなく『少しリッチなHDリマスター』
  23. 23. 23/ 136 物理ベースレンダリング CookTorrance + リニア空間 HDR LDR PSP Lambert & カラー描画 + sRGB空間 両方の全く異なるアーキテクチャを共存させる 特殊な 連携 / 結合 プロジェクトの大きな課題
  24. 24. 24/ 136 遥かなる遺産 - Legacy Imprement - PSP当時の様々な創意工夫が作品のビジュアルを構成 トーンカーブ エフェクト 線形フォグ 平行点光源 Bloomグレア 背景ぼかし
  25. 25. 25/ 136 一部の描画はPSPエミュレートで行う必要がある !! 残さなければならない実装が存在する 演出意図が変わってしまうことだけは避けたい!! MISSION発生!!
  26. 26. 26/ 136 フォグ -fog- 当時はNear/Farを使ったシンプルな線形補間 物理ベースでの光散乱をテストしてみたが濃度と輝度が全く一致しなかった ⇒エフェクト的にフォグ描画を活用している箇所が全滅 フォグ濃度計算結果(0~255)をGバッファに格納してHDRトーンマップ後にLDR合成
  27. 27. 27/ 136 トーンカーブ補正 –tone curve correction- カラーテーブルを参照して輝度から変換する方式。 ⇒当時はこれによってPSPでありながらも柔軟な色補正を実現していた 1Dテクスチャ & シェーダー でCLUTを再現してLDR空間で実装 トーン補正OFF トーン補正ON
  28. 28. 28/ 136 被写界深度 –depth of field- リアルタイムカットシーンのみ背景描画後に全画面ぼかし ⇒背景はぼけてキャラクターは後描きで鮮明にして表現されていた 被写界深度は距離計算の辻褄が合えば置換可能 !! リメイク刷新対象へ 刷新の詳細は後述
  29. 29. 29/ 136 エフェクト -VFX- 専用の内製ツールで緻密な調整が行われていた ⇒種類が膨大(5000種類超え)で、ブレンドモードも様々。 PSPハードウェア固有の特殊なブレンド機能も活用されていた…!!! 全VFXをHDR化するとすればそれはリメイクを意味する多大なコスト トーンマッピング完了後にエフェクトを後合成でLDR空間で描画 両社協議の結果、HDRへの移行は行わずLDRのままで続投と判断 ただ、まだ諦めてはいない…!! HDRにアプローチする別の手法を後述
  30. 30. 30/ 136 二方向の全く異なる方向性をまとめ上げることが 果たしてできるのか!? 出来ました…!!
  31. 31. 31/ 136 R G B A RT0 Albedo.R Albedo.G Albedo.B AO R8G8B8A8(sRGB) RT1 Normal.X Normal.Y Normal.Z MASK R10G10B10A2 RT2 Roughness Metalness Skin Emissive R8G8B8A8 RT3 Velocity.X Velocity.Y FOG Velocity符号 (X:1bit Y:1bit) R10G10B10A2 PSPのエミュレーションのために幾つかの特殊な構成が必要
  32. 32. 32/ 136 RT0 Albedo.R Albedo.G Albedo.B AO R8G8B8A8(sRGB) RT1 Normal.X Normal.Y Normal.Z MASK R10G10B10A2 RT2 Roughness Metalness Skin Emissive R8G8B8A8 RT3 Velocity.X Velocity.Y FOG Velocity符号 (X:1bit Y:1bit) R10G10B10A2 法線の裏表を表現する必要があったためZ値も 背景とキャラクターの判定マスク 肌表現を行うための対象マスク PSPの線形フォグ(0.0~1.0)
  33. 33. 33/ 136 速度バッファのR10G10B10A2へのエンコード 0.0付近が高精度になるように精度分布させる ⇒後述のTemporal Antialiasingで1ピクセル以下の精度が求められる なるべく数値情報を多く持てるように符号部を分離 ⇒高速な動きにも少しでも追従できるように ⇒数値部10bitと符号部1bitで実質 11bit 表現 RT3 Velocity.X Velocity.Y FOG Velocity符号 (X:1bit Y:1bit) R10G10B10A2 1bit 10bit +
  34. 34. 34/ 136 速度バッファのR10G10B10A2へのエンコード RT3 Velocity.X Velocity.Y FOG Velocity符号 (X:1bit Y:1bit) 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. 35. 35/ 136
  36. 36. 36/ 136 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. 37. 37/ 136 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 ); // y * 4 + x [1-cycle] if( alpha < ALPHA_THRESHOLD[sampleIndex]){ discard; } } エッジ補正 あり エッジ補正 なし ⇒アーティストで調整可能にパラメーター化
  38. 38. 38/ 136 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. 39. 39/ 136 物理ベースレンダリング 次世代への画質向上と新しいワークフロー
  40. 40. 40/ 136 DirectX11世代では標準的に採用される マテリアル質感の向上 品質の底上げ効果 シェーダーをシンプルに 異なる環境光下で安定した結果 リアリティー 一貫性簡略化
  41. 41. 41/ 136 長所:シェーダーをシンプルにできる 代表的なBRDFモデルを採用することで単一化可能 個別に専用に書いていたシェーダーから脱却できる ※但し、異方性を持った材質など特殊なものは別途考慮が必要 CookTorrance OrenNayar Specular Diffuse
  42. 42. 42/ 136 プログラマーの開発コストの低減 GPU実行効率の向上 バリエーション大量生成の回避 調整パラメーターの簡略化 (ラフネス&メタルネス)
  43. 43. 43/ 136 プログラム側のシェーダーメンテコストは低減できる …とはいえ3DモデルはPSP当時そのままでは使えない 3Dデーター構造がPSP世代と全く異なる!!
  44. 44. 44/ 136 PSP世代 DX11世代 カラーマップ Texture ○ - スフィアマップ Texture ○ - Albedo Texture - ○ 法線 Texture - ○ ラフネス Texture - ○ メタルネス Texture - ○ AO Texture - ○ IBL CubeTexture - ○ 必要な情報が全く違う!! アーキテクチャの違い ライティングモデル シェーダー有り無し 何もかもが別物!!
  45. 45. 45/ 136 PSP世代 DX11世代 カラーマップ Texture ○ - スフィアマップ Texture ○ - Albedo Texture - ○ 法線 Texture - ○ ラフネス Texture - ○ メタルネス Texture - ○ AO Texture - ○ IBL CubeTexture - ○ 唯一再利用できそうなのは… カラー…マッ..プ??? …しかしカラーマップと Albedoは概念が異なる
  46. 46. 46/ 136 ColorMap Texture 見た目の色味でコントロール 物理的に正確ではない アーティストの感性で調整していた Albedo Texture 外部からの入射光に対する反射光の比。反射能(はんしゃのう)とも呼ぶ。 物理的に反射率としての数値的意味がある。(0%~100% の 百分率で表現) 物質によって決まっている値。主に計測によって知ることができる。 Albedoの概念 Albedo = 0.7
  47. 47. 47/ 136 Albedoに陰影を含めてはならない 陰影をつけても暗くなるわけではなく『黒い材質』になるだけ。 陰影情報が取り払われたフラットなデーターが必要。 本来はカラーチャートとグレーシートを使って 計測後の輝度やホワイトバランスの補正が必要。 ※Albedoは0.0~1.0の表現で持てるため Gバッファ形式 R8G8B8A8 で十分使えた 「Albedo = 塗装色」と考えると影を塗ってはいけないことが分かり易い 例えば…
  48. 48. 48/ 136 Albedoには陰影を含めずに反射率を示す値として持つ
  49. 49. 49/ 136 プレイヤーキャラクターや主要オブジェクトはリメイク 物理ベースレンダリングに使用するフルクオリティ 当時ムービーレンダリング向けに使用されていた高品質モデル サブキャラクターと背景はPSPのジオメトリを再利用 カラーマップをAlbedoに再利用 & 辻褄が合うように調整 物理ベースパラメーターや法線マップは追加 テクスチャは4倍解像度(縦4倍 x 横4倍 = 16倍のピクセル数)へ変換 明らかに品質が足りないと判断されるジオメトリはリファインの対象へ 3Dモデルデーターの制作方針
  50. 50. 50/ 136 照明モデル刷新はPSP版原作スタッフによる再調整 HDR化によって照明の見た目が大きく変わってしまう ⇒光の当たり方も距離減衰も物理ベースレンダリングによって本質が変化 ⇒アーティスティックな演出とリアリティあるライティング 60fpsか?30fpsか? 性能的問題よりも原作システム構造上の制限のほうが大きかった 全実装を60fpsに置き換えるには多くの期間が必要だった。 ⇒60fps化は惜しみつつ見送ったが30fps分の処理余力全てを品質向上に回した グラフィックの演出指針
  51. 51. 51/ 136 パラメーター再調整後の3Dモデル ジオメトリがPSPのままでもパラメーターがしっかり入っていると質感が良い。 Albedo / Normal / AO roughness / metalness / emissive
  52. 52. 52/ 136 携帯機PSP ⇒ ハイエンドPS4/XboxOne据置 プレイヤーキャラクター「エース」の 例 PSP版 HD版 容量比 TRIANGLE 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 TOTAL 133 KB 28 MB 200 x 全体サイズは200倍に大幅に増大
  53. 53. 53/ 136 Color Albedo / Normal / Roughness Metalness / AO PSP版 HD版 1,074 triangle 41,333 triangle
  54. 54. 54/ 136
  55. 55. 55/ 136
  56. 56. 56/ 136
  57. 57. 57/ 136 スペキュラー項 Specular CookTorrance (GGX + Smith + ShrickFresnel) Microfacet Models for Refraction through Rough Surfaces [Walter07] Physically-Based Shading at Disney [Disney12] Chrome GGX Beckmann (実際の計測結果) GGXはBlinn Phongよりもテールが長い 現実の計測結果に一層近い 演算量と品質のバランスが良い もう少しテールが長いとより理想的。。。
  58. 58. 58/ 136 ディフューズ項 Diffuse OrenNayar OrenNayarはラフネス1.0以上のスーパーラフ(Super Rough)が表現でき、物理現象に近い特性。 高速化/処理負荷のために後に変更。やむをえず。。。。(´;ω;`) Lambert ⇒OrenNayarとLambertの見た目の差異が大きくないため今回は妥協。 ※ Wikipedia “オーレン・ネイヤー反射” より引用
  59. 59. 59/ 136 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; } Lambert演算量 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); } OrenNayer演算量 背に腹は代えられない…!! ライト単体だけで考えるとOrenNayerでも十分に テクスチャフェッチに隠れる。 Gバッファへのアクセスで隠蔽できる。 しかし複数光源で何回もループすると ALUサイクル数が地味に ボトルネックになる。
  60. 60. 60/ 136 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. 61. 61/ 136 ラフネスを補正することで近似表現 Real Shading in Unreal Engine 4 (SIGGRAPH 2013) [UE4SIG13] ラフネスでスペキュラーの鋭さを弱くして 擬似的にエリアライトを表現
  62. 62. 62/ 136 入射光の総和 = 出射光の総和 Diffuse ○% + Specular ○% = 100% Diffuse + Specular は光源のエネルギーを超えない 収束(Roughness=0.0)と拡散(Roughness=1.0)でも輝度エネルギーの総和は一致する GGX NDF(Normal Distribution Function) ではエネルギー保存を考慮した式になっている。 今回の物理ベースシェーダーでの実際の描画結果
  63. 63. 63/ 136 AO成分がある箇所でも光ってしまう問題を解決可能 最適化版が演算も高速で実用的 AOでの遮蔽でスペキュラー成分も遮蔽される。 CEDEC 2011 レンダリストのための物理ベースレンダリング –実装編– tri-Ace 五反田 義治氏 講演 Real-time Physically Based Rendering – Implementation [GOTANDA2011]
  64. 64. 64/ 136 Cubemapのミップレベルにラフネスの結果を畳み込む方式 今回はGGXを採用しているため GGXブラーカーネルを使った専用のGGXCubemap変換ツールを社内で作成。 それなりに重い処理のためCPUで行わずに GPU並列コンピューティングで重点サンプリング(Importance Sampling) 静的に事前生成 [GEMS3_IMP] GPU-based Importance Sampling (GPU Gems 3) 超一様分布列 Hammersley Sequence Sampling
  65. 65. 65/ 136 IBLで得られる環境光をスペキュラーにも反映 Practical Implementation of Physically-Based Shading Models at tri-Ace (SIGGRAPH 2010) [GOTANDA2010] Real Shading in Unreal Engine 4 (SIGGRAPH 2013) [UE4SIG13] 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 オフラインで生成した BRDFを考慮したGI反射適用
  66. 66. 66/ 136 今回実装したテスト結果 @ A B C Real Shading in Unreal Engine 4 (SIGGRAPH2013) [UE4SIG13] からの引用画像 A 重点サンプリングされた結果(Reference) B GGXブラー + AmbientBRDF C BのAmbientBRDFを2DLUT高速化近似
  67. 67. 67/ 136 GGX ブラーキューブマップ + AmbientBRDF テスト結果
  68. 68. 68/ 136 IBLの映り込みは視差補正して実際のシーンに合わせる [Parallax12] Local Image-based Lighting With Parallax-corrected Cubemap (SIGGRAPH 2012)
  69. 69. 69/ 136 IBLの映り込みは視差補正して実際のシーンに合わせる [Parallax12] Local Image-based Lighting With Parallax-corrected Cubemap (SIGGRAPH 2012) 窓の映り込みが一致しない ぴったり一致 !! 反射ベクトルをキューブサイズとジオメトリ距離とで補正
  70. 70. 70/ 136
  71. 71. 71/ 136 Uncharted2方式 Filmic Tonemapping を採用 Uncharted 2: HDR Lighting (GDC 10) [Naughty10] フィルム感光をシミュレートした応答。彩度をともなう発色が良好 ⇒露出自動補正と評価測光を追加実装して利用
  72. 72. 72/ 136 IBLや物理ベースの照明で多種多様な環境光下でも説得力ある結果が得られる
  73. 73. 73/ 136 影表現の最適化 クオリティーと実行速度の両立
  74. 74. 74/ 136 平行投影 + 3カスケード(1024x1024x3)を採用 XboxOne高速化のトレードオフで決定 ・1024x1024のResolve性能が良好 やはり・・・ Killzone2の手法が安定要素多く手堅かった ⇒テクセルのチラつきを無くすことが出来る ⇒視線方向の特異点がなく安定 ⇒平行移動だけでテクセルを再利用可能 リアルタイムイベントシーン用に1段目のみ高解像度化 ⇒2048x2048に切り替え The Rendering Technology of Killzone 2 [Michal09] 【参考】ShaderX6 “Stable rendering of cascaded shadow maps”
  75. 75. 75/ 136 高速化のためにサンプリングパターンを改良 実行サイクルを極小化 Texture.SampleCmp(sampler, uv, int2(offsetX, offsetY)); オフセット指定でサンプリングポイントを変えることでレジスタ消費を節約。 GCNアーキテクチャ(PS4 / XboxOne)にとって最適化効果が高い。 中景以降(2段目以降) はTemporalサンプリングを使用 ⇒Temporal Samplingについては後述 Secrets of CryENGINE 3 Graphics Technology, CRYTEK [CRYTEKSG11] 最適化したPCFテクセルサンプリングパターン 6 sample point
  76. 76. 76/ 136 半透明なオブジェクト影への対応 シャドウ生成時に透明度を反映 ⇒GBufferと同じくパンチ抜きで実装 Stochastic Renderingの簡易版 Stochastic Shadowmaps ・ディザノイズでレンダリングピクセルを散らす ・PCFで遮蔽計算と平滑化効果。ノイズを消せる ・4x4ディザパターンで実装 【検証GIFアニメーション】 フェードアウトする軍用クアール (影が滑らかにフェードアウト) 色つきシャドウにも拡張可能 Colored Stochastic Shadow Maps (NVIDIA) [McGuire11CSSM]
  77. 77. 77/ 136 全方位シャドウはScreen Space Raytraced Shadowで実装 適用範囲 エフェクトなどの動的光源での影 焚き火などの一部の演出効果 Gバッファのみで実装できる キューブマップ全方位シャドウより軽量 決して軽い処理ではない 階層Z(Hi-Z)を生成しレイトレース高速化 情報がない遮蔽の向こう側は背後は擬似的 ⇒しかし思っていたよりも意外と違和感が少なかった
  78. 78. 78/ 136
  79. 79. 79/ 136 全方位に放射状に広がる影
  80. 80. 80/ 136 Clustered Shadingでのカリング効果が高かった 照明計算と同時に行うと デプスフェッチしながらのレイトラバースが 複雑化でシェーダー最適化を阻害してしまう。 照明直後ディファード解決前の別パスで ライト累積バッファから照明計算の引き算で 照明を同輝度で±0相殺して影遮蔽生成 負の輝度を持つライト …!! 一度当てたライトを無かったことに出来る Deferred Resolve前であれば…
  81. 81. 81/ 136 TEMPORAL SUPER SAMPLING 処理負荷とグラフィック品質への対策
  82. 82. 82/ 136 グラフィックの品質向上に比例してGPU負荷が増大 GPU処理可能時間は有限 (60fps:約16.6ms / 30fps:約33.3ms) 高解像度化 シェーダー高度化 レイトレーシング 情報量増加 表現力向上 ラスタライズからサンプリングへ 表現の進歩により負荷が顕著に表面化
  83. 83. 83/ 136 CPUの場合はシングルコアからマルチコアへ 1つのCPUコアだけでは性能向上に限界があった 複数コアにして横方向への拡張でトータル性能を向上 マルチコアでは1つあたりの負荷が低い
  84. 84. 84/ 136 GPUの描画負荷を似た考え方で分散する手法 描画を1-Frameで全てを描画せず複数Frameに負荷分散 本作では複数の用途に活用し品質向上に大きく寄与 ⇒ アンチエイリアシング高速化 / 高品質化 ⇒ シャドウ 高速化 ⇒ SSAO 高速化 / 高画質化 ⇒ ローカルリフレクション (Screen Space Real-time Reflection) PIXEL
  85. 85. 85/ 136 当初は開発中期まではSMAAを採用していた SMAA: Enhanced Subpixel Morphological Antialiasing [JIMENEZ2012_SMAA] FXAAはぼやけるがSMAAはシャープな結果 ⇒破綻ケースが少ないため安定 FXAAよりも処理負荷が高い ⇒煉瓦の壁のエッジなど類似色になる境界線は効きが弱い ⇒判定精度を上げると解決する。しかし…さらに重くなる… 長所 短所
  86. 86. 86/ 136 処理負荷の最適化の過程でAAを高速化したかった 軽くすることでゲーム全体を一定量高速化できる期待 etc… アンチエイリアシングは常時負荷として計上されるフィルター FXAA SMAA MLAA MSAA MSAAは早い段階で選択肢から除外 性能面でSMAAより速くなることは無い。 AGAA 最近では Aggregate G-Buffer Antialiasing (NVIDIA I3D15) なども登場
  87. 87. 87/ 136 Temporal Super Sampling の考え方をAAに応用 AA無効の複数フレームからサブピクセル情報を収集。 エッジのピクセルの状態を蓄積して高品質な1-frameを構築。 1ピクセル未満のサブピクセルを蓄積するためMSAA並に綺麗!! frame frame frame frame frame 高品質 AA frame …は言い過ぎか?
  88. 88. 88/ 136 投影後のスクリーン座標にJitterオフセットを加算 ⇒サブピクセル分ずらして振動させることで情報量を増やすアイデア High Quality Temporal Supersampling / EPIC GAMES / SIGGRAPH2014 [BrianKaris] サンプリングパターンはMSAAでも採用されるHalton数列 Wikipedia “Halton sequence” より
  89. 89. 89/ 136 速度バッファで1フレーム前のピクセルを拾って再利用 Accelerating Real-Time Shading with Reverse Reprojection Caching [Nehab2007ARS] -velocity map - 速度バッファ
  90. 90. 90/ 136 速度バッファで1フレーム前のピクセルを拾って再利用 Accelerating Real-Time Shading with Reverse Reprojection Caching [Nehab2007ARS] 速度バッファの逆方向のピクセルを拾う 1フレーム前にあった場所の情報を拾うことができる AAには1ピクセル未満の値が表現できる精度が必要。 別でのオブジェクト遮蔽されていた場合は再利用しない デプス値の差が一定以上大きければ棄却する if 判定 画面外は遮蔽と同じく棄却対象 再利用できる部分のみを選別できる 現在 破棄 1フレーム前
  91. 91. 91/ 136 CryENGINE 3 Graphics Gems / Crytek [Sousa13] SMAA 1TX 今回の実装のベースになっている技法 (SMAAのテンポラル版) TL TR BL BR 2x2ピクセルの中点をバイリニアサンプルする4ピクセル平均 M 対象の中心ピクセル 【この手法のポイント】 1フレーム前の情報を合成するときに 現在の色で拘束するのではなく 隣接ピクセルの値で可動許容範囲を作っている MN N 1フレーム前の色をこのあそび領域範囲でクランプしてから合成 色が元の色から逸脱・破綻することがなくなる
  92. 92. 92/ 136 今回のためにサンプリングポイントを独自カスタム T RL B MM SMAA 1TXよりもピクセルの安定化効果(チラつき低減作用)が強い 参照範囲が広くなるため若干鮮明さが弱くなる。 SMAA 1TX TemopralAA改 customized version 長所 短所 テクセルフェッチ命令をSampleからLoadに変更できることで高速化も TL TR BL BR
  93. 93. 93/ 136 HDR最大の天敵『スペキュラーエイリアシング』 スペキュラー計算の結果、ハイライトが鋭い高輝度に。 鋭さが1ピクセル未満のサイズのハイライトになった場合 普通のラスタライズレンダリングではチカチカとピクセルチラつきになる。 高光沢の表面や遠景で起きやすい。 見た目がジャギやモアレ現象にも似ている。
  94. 94. 94/ 136 SMAANo AA TemporalAA改 TemporalAA改ではガタガタ感が大幅に低減 (但し若干高周波ディテールが弱まる) スペキュラーエイリアシングの抑制効果
  95. 95. 95/ 136
  96. 96. 96/ 136 手法 メモリ 消費 GBuffer 負荷 描画 負荷 輪郭 品質 遠景 品質 時間軸 安定 調整 難度 MSAA マルチサンプルAA × × △ ◎ ◎ ◎ ◎ FXAA ◎ ◎ ◎ △ △ × ◎ MLAA ◎ ◎ ○ ○ ○ × ◎ SMAA ◎ ◎ △ ◎ ○ △ ○ TemporalAA ◎ ◎ ◎ ◎ ◎ ◎ △ 速度 TemporalAA>SMAA 品質 TemporalAA>SMAA Temporal !! Temporal系のSMAA 1TX / TXAAも同様に時間軸方法の安定性が強力。 フレーム単体のAAよりTemporal方式のほうがチラつきが少ない。
  97. 97. 97/ 136 処理負荷を分散可能 軽い負荷で重い処理を実行できる。 1ランク、2ランク上の表現を導入できる可能性。広い応用範囲。 非常に高いアンチエイリアシング効果 16xAAに匹敵する品質をFXAA並の軽い負荷で。 時間軸方向のちらつきの高い抑制効果。但し調整にクセがある。 HDR時代スペキュラーエイリアシングへの突破口 高輝度スペキュラーのちらつきとの決別。ひとつの選択肢に。 導入で劇的な改善効果が見込める。但し鋭いハイライトで少しディテールが潰れる スペキュラーAAは他の手法も多数 (VMF / LEAN / CLEAN / Toksvig etc...)
  98. 98. 98/ 136 光学フィルターと特殊描画パス HDRとLDRの共演 / PSP版の表現との共存
  99. 99. 99/ 136 HDRレンズエフェクト 前後 LDR VFX レンズエフェクトは別のHDRバッファに蓄積しておき最終段で合成 ⇒レンズ内で発生する現象は一番手前レイヤーで適用されている必要あり 今回VFXはLDRで移植になったためLDR空間の後段パスにVFXが存在。 ⇒VFX後にレンズエフェクトを合成。 ⇒別枠で後合成するためトーンマッピングを考慮して輝度トーン補正を適用 ・・・・・・
  100. 100. 100/ 136 TemporalAAのJitterをGBuffer生成時に実装した場合 最終イメージ出力までにTemporalAAで揺れを解決する必要がある。 ⇒途中パスで解決前のバッファを使用したときは別途解決が必要。 ⇒今回はHDR/LDR混在の特殊環境で定石となる描画順は踏めず適用箇所が本来とは異なり複数必要だった。 光学系 グレア 光学系 レンズフレア 光学系 残光 GBuffer 生成 (MRT) 光源 IBL 天球 トーン マッピング VFX (半透明) HUD 輝度 抽出 TAA 光学系 DOF SSRTAA モーション ブラー TAA トーン マッピング グレア系は本来のHDRで処理するが LDRエフェクトが描き終わった後の 最前面レイヤーに必要だった LDRHDR DOF前に解決が必須 LDRエフェクトのエッジ解決 揺れ解決前に参照されるために 縮小バッファに別途解決 LDR後段パス合成のために 別途適用 今作のHDR/LDR混在の特殊描画の流れ SSAO なぜローカルリフレクションの位置がここに?(後述)
  101. 101. 101/ 136 TemporalAAの「もうひとつのメリット」 ⇒TemporalAA(TAA)はAA効果以外にTemporal Super Samplingで安定化が望める ⇒当初は高速化の目的で選択したが、シーン全体の画質向上に絶大な効果があった 光学系 グレア 光学系 レンズフレア 光学系 残光 GBuffer 生成 (MRT) 光源 IBL 天球 トーン マッピング VFX (半透明) HUD 輝度 抽出 TAA 光学系 DOF SSRTAA トーン マッピング グレア系は本来のHDRで処理するが LDRエフェクトが描き終わった後の 最前面レイヤーに必要だった LDRHDR DOF前に解決が必須 LDRエフェクトのエッジ解決 LDR後段パス合成のために 別途適用 今作のHDR/LDR混在の特殊描画の流れ SSAO なぜローカルリフレクションの位置がここに?(後述) 揺れ解決前に参照されるために 縮小バッファに別途解決 モーション ブラー TAA
  102. 102. 102/ 136 ポストエフェクトフィルター 光学的表現とLDRとの共存
  103. 103. 103/ 136 ポストエフェクト描画負荷は全体の約50% ⇒テクスチャ解像度を上げているとはいえ 基本的にモデルデーター素材はPSP当時のもの。 品質向上のために負荷でポストエフェクトが占める割合を高くした。 HDRフィルター/LDRフィルター 共存矛盾の問題が発生!! HDR/LDR混在の特殊な構成
  104. 104. 104/ 136 本来は全てHDR空間で行いたいがLDR VFXが存在。 エフェクト前と後で掛けるフィルターを吟味…!! Bloom アナモルフィックレンズフレア レンズフレア 残光 SSAO PSP互換Bloom 被写界深度 ローカルリフレクション モーションブラー カラートーンカーブ補正 HDR空間で実行 LDR空間で実行 !? !? !? LDR !?
  105. 105. 105/ 136 これら3つのフィルターは少なくともVFXを含めた結果であるべき ⇒VFXの表現と連携するためにLDR化したフィルターが必要になった。 ⇒LDRのままでは見た目が退化するためHDR補正を掛けて適用 Bloom アナモルフィックレンズフレア レンズフレア 残光 SSAO PSP互換Bloom 被写界深度 ローカルリフレクション モーションブラー カラートーンカーブ補正 HDR空間で実行 LDR空間で実行 !? !? !? LDR !?
  106. 106. 106/ 136 当時アーティストによって綿密に調整されていたVFX ⇒見た目での調整ではあるものの、ベストだと判断された結果によるもの ⇒光や炎、魔法表現が美しいFINAL FANTASYの効果美術 言い換えると… トーンマッピング後の結果をアーティストが自身の感性で描き上げたに等しい
  107. 107. 107/ 136 1.0 0.0 HDR輝度のVFX ??? 逆トーンマッピング (Inverse Tonemapping) ⇒HDR空間のものをLDR空間に落とし込む手法がトーンマッピング ⇒(必ずしも正確ではないが) LDR空間から逆算して本来のHDR空間輝度を推定できないか? 物理ベースと異なりad-hocな対応ではあるものの 全く補正を掛けないときよりも見た目は大きく向上 前世代までの明るい部分を抽出してグレアにする手法に近い。 トーンマッピングを考慮して、もう少し厳密に行なったバージョン。 HDR LDR VFX 逆トーンマッピング 1.0 0.0 1.0 0.0 HDR空間 LDR空間 HDR空間
  108. 108. 108/ 136 HDR縮小バッファでは輝度差でバイリニアフィルタ特有の 四角い拡大アーティファクトがより顕著に目立つように アンチ縮小バッファアーティファクト (CEDEC 2009) [Kawase09] 通常描画時 アーティファクト対策後 実際の実装と対策の検証比較 品質的に問題ないレベルに改善 非常に良い手法だった
  109. 109. 109/ 136 感覚的 / 経験則的に眩しさを感じさせる効果 高輝度で残像。簡易的な網膜の残像シミュレート表現を行う。 ⇒プルキンエ (プルキニェ) 現象 (Purkinje effect) 桿体細胞の影響で青色系にカラー変化を起こすフェードアウト
  110. 110. 110/ 136 AOマップだけでは表現できない動的な遮蔽項の生成 Scalable Ambient Obscurance (HPG12) NVIDIA [McGuire12SAO] の手法をベースに実装 高速化のために前述の Temporal Super Sampling 拡張実装 1フレームに1サンプルしか 遮蔽判定フェッチしていない GPU負荷1ms以下で非常に高速 Temporal化でノイズが抑えられた
  111. 111. 111/ 136 映像のフォーカス / ピンぼけ表現 絞り形状を伴うぼけ表現。旧来のガウス暈しと比較すると空気感が違って見える LDR空間で適用が必須条件 ⇒前述のHDR補正を行った 高輝度成分に絞り形状が現れる
  112. 112. 112/ 136 対象物をロックオン(注視)したときにDOF 新規導入 ・ゲーム中での記号的意味合い。注視感・臨場感が増す ・カメラがズームするときにフォーカスが連動する ・ F値、レンズ焦点距離など厳密なレンズシミュレートは今回は都合上見送った
  113. 113. 113/ 136 当初はシーンに速度感/躍動感を与えるために導入 フレーム補間効果で、30fps動作での動きの滑らかさ向上 リアリティを感じさせる相乗効果が得られた
  114. 114. 114/ 136 フレーム間の中間情報の内挿で情報量が増加 時間 カクカク感が大幅に低減され、動きへの目線追従効果も。 今作では 2pass 36tap サンプルのブラー生成 仮想的にフレームレートが増加する
  115. 115. 115/ 136 全方位探索方式と異なりサンプリング負荷が低いアルゴリズム A Reconstruction Filter for Plausible Motion Blur (NVIDIA) [McGuire12Blur] 周辺の速度最大値を生成 今回は独自にカスタム ・64x64タイルで適用 ・解像度30x16の速度バッファ ・ブロックアーティファクト低減 高いL2キャッシュヒット率で高速。広範囲のブラーを可能に。 Ryseでの実用事例も参考になった。 CryENGINE 3 Graphics Gems [Sousa13]
  116. 116. 116/ 136 参考比較画像 HDRを考慮したLDR空間でのHDR補正つきブラー生成 補正でLDR VFXもHDRのような振る舞いをする HDR補正はDOFにも適用
  117. 117. 117/ 136
  118. 118. 118/ 136 別名: Screen Space Ray-traced Reflections (SSRR) GBufferで反射計算、デプスバッファをレイマーチ Taking Killzone Shadow Fall Image Quality Into The Next Generation [Michal14] スクリーン空間で実行するため専用の構造が必要ない ラフネスを考慮したブラーでリフレクションにラフネス反映 ・HiZを生成してなるべく低解像度&広いステップでレイマーチ開始 ・探索を早めの距離で打ち切る (打ち切っても遠景ではさほど問題にならない) ・Jitterでランダムサンプリング & Temporal Super Sampling で安定化 高速化Tips
  119. 119. 119/ 136 ローカルリフレクション OFF
  120. 120. 120/ 136 ローカルリフレクション ON
  121. 121. 121/ 136 ローカルリフレクション OFF
  122. 122. 122/ 136 ローカルリフレクション ON
  123. 123. 123/ 136 2次反射 1次反射 通常レンダリング結果 リフレクション成分のみ テスト表示 1フレーム前の結果をリプロジェクションでリフレクションソースとして使う ⇒2次反射・3次反射…とフィードバック繰り返し反射するためGIを近似できる 相互反射の発生 3次反射 Specular 成分
  124. 124. 124/ 136 今回は本来の適用タイミングで適用出来ない問題があった… 光源 IBLSSR 光源 IBL SSSSS Deferred Resolve Specular Diffuse HDR トーン マッピング LDR 光源 IBLSSR 光源 IBL SSSSS Deferred Resolve Specular Diffuse HDR トーン マッピング LDR SSR 本来のワークフロー 今作の特殊フロー ローカルリフレクションとIBLとをブレンドしてスペキュラー項生成 トーンマッピングも全て終わった事後に合成しなければならない。IBLとの競合は避けられないが 輝度はHDR補正で解決。合成フェーズは各成分を分離計算するため複雑。
  125. 125. 125/ 136 表面下散乱 なし 表面下散乱 あり
  126. 126. 126/ 136 ポストエフェクトで表面下散乱を表現 シンプルな実装で十分な品質 ディフューズ成分のみにブラー スペキュラーとディフューズは分離 スキン部分にマスクで局所適用 ライト累積バッファを Diffuse / Specular 別々に処理 ⇒ 合成前にSSSSSを適用。 Screen-Space Perceptual Rendering of Human Skin [JIMENEZ2010_GPUPRO]
  127. 127. 127/ 136 光量の不足や強い照明がキャラクターにあたった場合 ⇒凹凸によってコントラストが非常に強くなる。 ⇒角度によっては見た目が怖い場合もあり得る(真下からの強いライトなど) ポートレート写真ではレフ照明で陰影を和らげる撮影手法がとられる いかなる環境下でもキャラクターが映えるように補助的に適用 やわらかな間接照明1灯ではなく 半径が小さめの光源を3灯 角度を変えて当てる 複数光源でライトアップすることで 目にハイライトが入る副次的効果 キャラクターが活きて見える
  128. 128. 128/ 136 レフ照明 なし レフ照明 あり
  129. 129. 129/ 136 レフ照明 なし レフ照明 あり
  130. 130. 130/ 136 まとめ FINAL FANTASY 零式 HD 開発
  131. 131. 131/ 136 原作の良さと新しい表現の両立に成功 工夫次第で現行の技術トレンドを織り込むことが出来る!! 新しいHD化の可能性が見えた 単なるHDリマスターの領域を超えた映像表現が不可能ではなかった!! 当初の想定よりも多くの見識を得た 急な方針転換で開発は大変だったが大英断だった!! SQUARE ENIX FINAL FANTASY 零式HD 開発チームと ヘキサドライブの連携体制によって双方に技術の蓄積ができた。 綺麗になった !! 素直に喜ばしい
  132. 132. 132/ 136 物理ベースレンダリングでの留意点/課題 輝度単位の統一はきわめて重要 !! (照明 / IBL / エミッシブ の輝度) ⇒いくら破綻しないという物理ベースでも基準が異なると簡単に破綻。 HDRスペキュラーエイリアシングをどう対処するか?に終始。 ⇒ミップマップ&異方性フィルタ でモアレを除去しても… アンチエイリアシングで輪郭のジャギー(エイリアシング)を除去しても… スペキュラーエイリアシングが全てを台無しにしてしまう・・・!!! 今回は Temporal Antialiasing でこの問題を複合的に解決した 今回はスケールをPSPにあわせてLDR両立の別単位を作る必要があった
  133. 133. 133/ 136 [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. 134. 134/ 136 [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. 135. 135/ 136 当資料内 「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. 136. 136/ 136

×