Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 218 Anuncio

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

Descargar para leer sin conexión

2017年1月21日に行われたライセンシー様向けマテリアル管理勉強会の資料です。(登壇者: 株式会社SQEX大阪 林武尊様)

「大規模チーム」、「エフェクト」、この二点を軸に、爆発するマテリアル管理や検証をどのように行っているかを説明しただいております。
時間の都合で本編ではカットされた内容も沢山盛り込まれております。

2017年1月21日に行われたライセンシー様向けマテリアル管理勉強会の資料です。(登壇者: 株式会社SQEX大阪 林武尊様)

「大規模チーム」、「エフェクト」、この二点を軸に、爆発するマテリアル管理や検証をどのように行っているかを説明しただいております。
時間の都合で本編ではカットされた内容も沢山盛り込まれております。

Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (14)

Anuncio

Más de エピック・ゲームズ・ジャパン Epic Games Japan (20)

Más reciente (20)

Anuncio

大規模タイトルにおけるエフェクトマテリアル運用 (SQEX大阪: 林武尊様) #UE4DD

  1. 1. ©2016 SQUARE ENIX CO., LTD. All Rights Reserved.©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Deep Dive 大規模タイトルのエフェクトマテリアル運用 株式会社スクウェア・エニックス 林 武尊 公開版
  2. 2. 略称について 略称について • 『Unreal Engine 4』をスライド内では『UE4』と記載しています • 『PlayStation®4』も同様に『PS4』と記載しています ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  3. 3. 自己紹介 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  4. 4. 自己紹介 • 林 武尊( TAKERU HAYASHI ) • エフェクトアーティスト • KINGDOM HEARTS シリーズ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  5. 5. 今日お話する内容 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  6. 6. 今日お話する内容 • UE4を使ったPS4の大規模タイトルでの事例 • 経験したことのないスタッフ数 • エフェクトチームでのマテリアルの運用のお話 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 内容
  7. 7. 今日お話する内容 • ファンタジックなエフェクトが沢山出る • 色々と四苦八苦したお話 • スライドはDLしてご覧ください ノートの方で大量に補足しています ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 前提として‥
  8. 8. 今日お話する内容 • 世の中にまだまだ情報が少なくて苦労した これから取り掛かる方に少しでも参考になって欲しい • 色んな会社さんが事例をどんどん出していって欲しい 今回の講演がそのきっかけの1つになれば嬉しい ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 講演の目的
  9. 9. 今日お話する内容 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. アジェンダ • エフェクトアセットの概要 あるタイトルでの事例 • アセット管理 • アセット管理での工夫 • ファイルサイズの計測 • チェック環境 補足事項 • テクスチャ • マテリアル • マテリアルの利便性向上
  10. 10. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  11. 11. エフェクトアセットの概要 ここに1つのエフェクトがあったとする ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  12. 12. エフェクトアセットの概要 エフェクトは複数のエミッターで構成される ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  13. 13. エフェクトアセットの概要 エミッターはパーティクルの発生源 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  14. 14. エフェクトアセットの概要 パーティクルを1つだけ生成したり沢山生成したり ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 1つだけ 沢山
  15. 15. エフェクトアセットの概要 1つのエミッターで1つのマテリアルを使う Mat Mat Mat Mat Mat Mat ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  16. 16. エフェクトアセットの概要 1つのマテリアルに複数のテクスチャを使ったりもする Tex A Mat Tex B ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. エミッシブカラー オパシティ
  17. 17. エフェクトアセットの概要 エフェクトのテクスチャはモノクロで十分な場合が多い ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  18. 18. Tex C エフェクトアセットの概要 テクスチャを歪ませるために別のテクスチャも使う Tex A Mat Tex B ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. エミッシブカラー オパシティ
  19. 19. Tex C エフェクトアセットの概要 千切れていく表現のために別のテクスチャも使う Tex A Mat Tex B ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Tex D エミッシブカラー オパシティ
  20. 20. エフェクトアセットの概要 つまりエフェクトはテクスチャを沢山使う ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  21. 21. エフェクトアセットの概要 エフェクトのUE4上での参照関係はこんな感じになる Tex Tex テクスチャマテリアル MatInst Master ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Tex Tex エフェクト エミッターA エミッターB エミッターC エミッターD 差し替え分 デフォルト指定
  22. 22. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 次はエフェクトでメッシュを扱う場合について
  23. 23. エフェクトアセットの概要 パーティクルは大きく分けてスプライトとメッシュ スプライト メッシュ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ※本スライドでは「スプライトパーティクル」と呼称
  24. 24. エフェクトアセットの概要 メッシュパーティクルの場合 元のマテリアルをオーバーライドできる メッシュ Mat Mat ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  25. 25. エフェクトアセットの概要 もしもオーバーライドできる機能が無かった場合‥ 同じ形状でもマテリアルの数だけメッシュの用意が必要 Mat ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ・・・ Mat Mat Mat Mat メッシュ
  26. 26. エフェクトアセットの概要 エフェクトのUE4上での参照関係はこんな感じになる Tex Tex テクスチャマテリアル MatInst Master メッシュ Mdl ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Tex Tex エフェクト エミッターA エミッターB エミッターC エミッターD Mat Tex オーバーライド 差し替え分 デフォルト指定
  27. 27. エフェクトアセットの概要 つまり1つのエフェクトでこれだけのアセット量になる Mat Mat Mat Mat Mat Mat ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Mdl Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Tex Master Master Master Master Master Master Tex Tex Tex Tex Tex Tex Tex Tex Mat Tex
  28. 28. エフェクトアセットの概要 まとめると‥ • エフェクトは沢山のマテリアルを使って表現する • マテリアルとテクスチャを組み合わせる • マテリアルとメッシュを組み合わせる • それらの組み合わせは非常に膨大! ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  29. 29. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 実際にどんなテクスチャ・マテリアル・メッシュを 最初に用意するかというと、汎用的なものになる
  30. 30. エフェクトアセットの概要 エフェクトの汎用アセットはこんなイメージ Tex Tex Tex テクスチャ Tex Tex Tex Tex Tex Tex Tex Tex Tex マテリアル Mat Mat Mat Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst メッシュ Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  31. 31. マテリアル Mat Mat Mat Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst エフェクトアセットの概要 メッシュとマテリアルの組み合わせについて メッシュ Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl Mdl ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. パーティクル側でマテリアルをオーバーライド可能なので メッシュとマテリアルそれぞれ必要数だけの用意で済む
  32. 32. マテリアル Mat Mat Mat Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst Mat Inst エフェクトアセットの概要 マテリアルとテクスチャの組み合わせについて Tex Tex Tex テクスチャ Tex Tex Tex Tex Tex Tex Tex Tex Tex ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 問題はこちらで、マテリアルとテクスチャの組み合わせ分の マテリアルインスタンスを用意しないといけない しかもパラメータ違いなどもあるので膨大な数に及んでしまう
  33. 33. エフェクトアセットの概要 マテリアルインスタンスがテクスチャの数だけ増える マスターマテリアル A ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Mat Inst A Mat Inst B Mat Inst C マスターマテリアル B Mat Inst A Mat Inst B Mat Inst C ただ、マテリアルインスタンスのファイルサイズは極小なので 同じ組み合わせがあちこちに生まれても良しとするのもアリかも
  34. 34. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. マスターマテリアル自体も結構な数が必要になる
  35. 35. エフェクトアセットの概要 例えばリアル系の世界観でシューターだったりすると‥ 炎、マズルフラッシュ、爆発、薬莢、煙、水飛沫 ‥のような表現したいカテゴリごとにマスターマテリアル を何種類かずつ用意するというような形で済む? ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  36. 36. エフェクトアセットの概要 しかし、ファンタジーな世界観かつ大量にエフェクトを 作成するためにも、汎用的なマテリアルの組み合わせで なるべく賄いつつ‥ しかし特殊な表現を求められることも多いので 各場面で固有のアセットも必要になる ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  37. 37. エフェクトアセットの概要 そのため基本的には ① 汎用アセットをメモリに常駐させる ② 常駐アセットをフル活用してエフェクトを作成 ③ 読み込みが許容できる範囲内で固有アセットを作成 これが基本的なデータの持ち方になる ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  38. 38. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. かといって何でもかんでも常駐させる訳にはいかない メモリ使用量・使用効率を考えつつ‥ ゲーム起動時のロード時間とのトレードオフになる
  39. 39. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ではどんなアセットを常駐させるのかというと ゲーム中の読み込み時にネックになるアセット つまりゲーム中の使用頻度が高い上で 「サイズが大きい」ものと「数が多い」もの 今後、ロード処理の抜本的な変更により 細かなアセットのロードも改善されるとのこと
  40. 40. エフェクトアセットの概要 では各アセットのファイルサイズはどの程度なのか? 容量が大きくなるのは主にテクスチャだけではなく 現状ではマテリアルもかなり容量を占める ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. マテリアルのサイズはUE4.14で大きく削減されるとのこと
  41. 41. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • TC_Default (DXT1) • TC_Default (DXT5) • TC_Alpha (BC4) • VectorDisplacementmap (非圧縮4チャンネル) テクスチャのサイズ ※PS4向けにクック後のファイルサイズ / 全てMipmapあり UE4.13で計測 ‥1024x1024で約680KB ‥1024x1024で約1370KB ‥1024x1024で約680KB ‥1024x1024で約5460KB
  42. 42. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マスターマテリアル 標準(半透明/Unlit) 不透明でやや複雑 半透明でDefaultLit デカールでやや複雑 • マテリアルインスタンス マテリアル関数 マテリアルのサイズ ※PS4向けにクック後のファイルサイズ UE4.13で計測 ‥約110~140KB ‥約230~270KB ‥約470~480KB ‥約280~320KB ‥約1~3KB ‥約1.6~2KB
  43. 43. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 標準的なもの ‥約3~20KB • 重ためのもの ‥約30~70KB スタティックメッシュのサイズ ※PS4向けにクック後のファイルサイズ UE4.13で計測
  44. 44. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. これらを踏まえると‥ • テクスチャとマスターマテリアルは常駐の対象 • メッシュは容量は小さめだが使用頻度が高いものは 常駐させて良いように思う • マテリアルインスタンスは容量は極小だが UE4.11~12当時はファイル数が多いことがロードの ネックになっていたので常駐に含めていた 今後のロードの改善に合わせて方針も変わりそう
  45. 45. エフェクトアセットの概要 加えて‥ エフェクトはゲーム中に突発的に表示されるものが多い (プレイヤーの技など) 読み込みの観点から、いつでも突然表示される可能性が あるエフェクトは常駐アセットで賄い 読み込みを挟んでもOKなものは固有アセットを併用 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  46. 46. エフェクトアセットの概要 読み込みOKな例は‥ ・読み込み前提の大技のエフェクト ・ボスのエフェクト(レベルに紐付く) ・レベルに配置する背景エフェクト(レベルに紐付く) ・カットシーンエフェクト(レベルに紐付く) ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  47. 47. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. プレイヤーの汎用技 汎用的に配置されるもの いつでも出る可能性のあるもの プレイヤーの読み込み技 ボス カットシーン 背景エフェクト 固有アセット 理想 テクスチャ、メッシュ、マテリアル メモリに常駐させるアセット レベルに依存しないもの レベルに依存するもの
  48. 48. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. テクスチャ、メッシュ、マテリアル プレイヤーの読み込み技 ボス カットシーン 背景エフェクト プレイヤー 汎用配置物など プレイヤーの汎用技 汎用的に配置されるもの いつでも出る可能性のあるもの 実際常駐させる固有アセットメモリに常駐させるアセット レベルに依存しないもの レベルに依存するもの
  49. 49. エフェクトアセットの概要 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 以上がエフェクトアセットの概要になります
  50. 50. ©2016 SQUARE ENIX CO., LTD. All Rights Reserved. あ る タ イ ト ル で の 事 例 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  51. 51. あるタイトルでの事例 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ちょっと特殊なケース 大規模プロジェクトのチーム構成&アセット構成だが ゲーム全体ボリュームは小さめなのでその点は参考程度で
  52. 52. あるタイトルでの事例 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. まずエフェクトのアセット数と容量の結果から
  53. 53. 211 161 353 61 193 62 3 40 108 38 1 82 125 6 195 242 330 22 215 603 30 テクスチャ マテリアル インスタンス 関数 メッシュ パーティクル その他 あるタイトルでの事例 ○ エフェクトの総アセット数 約3000 常駐指定1000 プレイヤー400 固有アセット1600 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 446個 511個 721個 84個 490個 790個 40個 ※常駐テクスチャの大多数は実際にはストリーミングされていた UE4.13で計測
  54. 54. あるタイトルでの事例 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 21 67 1 0 6 6 0 9 34 0 0 14 22 0 132 98 1 0 44 52 0 テクスチャ マテリアル インスタンス 関数 メッシュ パーティクル その他 ○ アセットの総ファイルサイズ 約500 MB 常駐指定100 MB プレイヤー80 MB 固有320 MB 162MB 200MB 2MB 0MB 64MB 80MB 0MB ※常駐テクスチャの大多数は実際にはストリーミングされていた UE4.13で計測
  55. 55. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  56. 56. アセット管理 エフェクトで扱うアセットの種類 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • テクスチャ • マテリアル関連 • スタティックメッシュ • パーティクルシステム • データアセット • スケルトン • アニメーション • 各種ブループリント 作成するもの 編集だけするもの
  57. 57. アセット管理 プロジェクト全体の主なフォルダ構成 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. level effect ‥ characer content エフェクトはここで一元管理
  58. 58. アセット管理 エフェクト全体の主なフォルダ構成 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. level useful common enemy player effect レベルに紐付かないもの レベルに紐付くもの (背景、ギミック、カットシーン)
  59. 59. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. level useful common enemy player effect メモリに常駐させるアセット 常駐させないが汎用的なアセット エフェクト全体の主なフォルダ構成 管理者だけ編集可
  60. 60. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. level useful common enemy player effect 各地にちらばっている 汎用的なアセットを移動 エフェクト全体の主なフォルダ構成
  61. 61. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. level useful common enemy player effect エフェクト全体の主なフォルダ構成 使用頻度が低いなら降格 使用頻度が高いなら昇格
  62. 62. アセット管理 エフェクト常駐アセットの主なフォルダ構成 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. mat_dcl tex mdl mat_mdl mat_par mat_master common マスターマテリアル マテリアルインスタンス(スプライト用) マテリアルインスタンス(メッシュ用) マテリアルインスタンス(デカール用) スタティックメッシュ テクスチャ
  63. 63. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. マスターマテリアルについて
  64. 64. アセット管理 エフェクトのマテリアルで扱う主な要素 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • アルファ合成 / 加算合成 • 両面 / 片面 • Particle Colorの反映 • 頂点カラーの反映 • テクスチャの反映 • SubUVアニメーション • UV周りの設定 • Dynamic Parameter • ソフトパーティクル • フレネル • ニアフェード • その他いろいろ‥
  65. 65. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. これらの組み合わせをそのまま用意しようと思うと‥
  66. 66. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. マスターマテリアルが組み合わせ爆発を起こす アルファ 加算 両面 片面 ParCol あり ParCol 無し VerCol あり VerCol 無し 通常TEX SubUV カラー モノクロ DynParam あり DynParam 無し ソフトあり ソフト無し フレネルあり フレネル無し フェードあり フェード無し 1024種類
  67. 67. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. なので何を制限・統一するかという話になる アルファ 加算 両面 片面 ParCol あり ParCol 無し VerCol あり VerCol 無し 通常TEX SubUV カラー モノクロ DynParam あり DynParam 無し ソフトあり ソフト無し フレネルあり フレネル無し フェードあり フェード無し 64種類
  68. 68. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 組み合わせを必要最小限にするための精査
  69. 69. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. まずはエフェクトのマテリアルに必要な基本設定から
  70. 70. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • アルファ合成 か 加算合成 か ⇒ どちらも使うケースがある Blend Mode アルファ合成 加算合成
  71. 71. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ライティングあり か 無し か ⇒ どちらも使うケースがあるが基本的には無し Shading Model あり 無し
  72. 72. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 片面 か 両面 か ⇒ どちらも使うケースがあるが基本的には両面 両面処理 両面じゃないと困る例1 両面じゃないと困る例2
  73. 73. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 半透明を別バッファに描き被写界深度の後に合成する またいわゆる縮小バッファとして利用できる あり か 無し か ⇒ 基本的には無し Separate Translucency Separate Translucency OFF 被 写 界 深 度 Separate Translucency ON 不 透 明 描画の流れ
  74. 74. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 半透明へのTemporal AAの影響をマスクする あり か 無し か ⇒ Temporal AAを使用しないので無し Responsive AA
  75. 75. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • する か しない か ⇒ 拡張対応面で便利なものの今回は無しで運用 次の機会に使ってみたい マテリアルアトリビュートを使用
  76. 76. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 次にエフェクトのマテリアルに必要な機能について
  77. 77. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • エフェクト側から色を与えるノード構成 あり か 無し か ⇒ 基本的にあり 使用しないのは屈折マテリアルなど一部の例外のみ Particle Color あり 無し
  78. 78. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • メッシュの頂点カラーを取得するノード構成 あり か 無し か ⇒ 不要なものも沢山あるが基本的にあり スプライトパーティクルには必要ないが全てに内包 頂点カラー あり 無し
  79. 79. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • TextureSamplerノードで色を与える構成 カラー か モノクロ か ⇒ どちらも使うケースがある Sampler Typeの種類分だけ数が増えるので‥ カラーはDXT1、モノクロはBC4で統一 テクスチャの種類 DXT1 BC4
  80. 80. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 余談 テクスチャを使用する か 固定値 か ⇒ マテリアルの種類を増やしたくなかったので 必ずテクスチャを使用する形にした 固定値は1x1ドットの真っ白テクスチャを使う テクスチャの種類 1x1
  81. 81. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • フリップブックアニメーションが可能なノード構成 通常のテクスチャ か SubUVを利用する か ⇒ どちらも使うケースがある パターン切り替え時にブレンド補間が可能 全てParticleSubUVにするという選択肢もある? Particle SubUV
  82. 82. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • UVのタイリングやスクロール速度を指定する構成 あり か 無し か ⇒ タイリングに関しては基本的にあり 1. 全てのテクスチャノードはタイリング可能 2. メッシュ用ではスクロール速度を指定可能 UV周りの設定
  83. 83. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 余談 エフェクト側の機能としてマテリアル全体の UVの90度回転とタイリング数の指定が可能なよう拡張 UV周りの設定 90度回転 タイリング
  84. 84. • エフェクト側からの動的な値をマテリアルで取得する あり か 無し か ⇒ どちらも使うケースがある UVスクロールやUVの初期値ランダム用にメッシュ限定で使用 アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Dynamic Parameter
  85. 85. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • いわゆる「ソフトパーティクル」を行うノード構成 あり か 無し か ⇒ どちらのケースもある GPU負荷もあるので全てのマスターマテリアルには含めない Depth Fade あり 無し
  86. 86. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • いわゆる「フレネル」を行うノード構成 あり か 無し か ⇒ どちらのケースもある 大抵はメッシュパーティクル用途に限られる Fresnel あり 無し
  87. 87. • カメラ方向にパーティクルの位置をズラすノード構成 あり か 無し か ⇒ GPUパーティクル用途では欲しい エフェクト側に代替となる機能を追加拡張 なのでマスターマテリアルには含めない アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. カメラオフセット ※GPUパーティクルではCamera Offset モジュールが使えないため
  88. 88. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • パーティクルがカメラに近いとフェードするノード構成 あり か 無し か ⇒ どちらのケースもあるが基本的には無し どうしても欲しい場合は固有マテリアルで対応 ⇒ 後にエフェクト側に機能を追加拡張 ニアフェード
  89. 89. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 以上をベースにして必要最小限の組み合わせを決めた アルファ 加算 カラー モノクロ 通常 SubUV ソフトあり ソフト無し フレネルあり フレネル無し 32種類 SubUVに統一できるならさらに半分に減る‥ モノクロに統一できるならさらに半分に減る‥
  90. 90. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 統一性を取るならこのような感じだが‥ アルファ 加算 カラー モノクロ 通常 SubUV ソフトあり ソフト無し フレネルあり フレネル無し 32種類 両面 頂点カラー:あり UVタイリング指定 ・ スクロール速度指定 DynamicParameterはどうしよう‥
  91. 91. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. スプライトパーティクル用途の場合 アルファ 加算 カラー モノクロ 通常 SubUV ソフトあり ソフト無し メッシュパーティクル用途の場合 アルファ 加算 カラー モノクロ ソフトあり ソフト無し フレネルあり フレネル無し 16種類 16種類 DynamicParam含む
  92. 92. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. さらに千切れマスターマテリアルが欲しいとなった場合‥ アルファ 加算 カラー モノクロ 通常 SubUV ソフトあり ソフト無し フレネルあり フレネル無し 32種類 8 いくつか制限を決めて8種類をリリース‥という感じ モノクロのみに制限できるならさらに半分に減る
  93. 93. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ただしスプライトパーティクル用のマテリアルを メッシュパーティクルに転用したり、その逆も考えられる ので、設定は統一できるところは統一した方が良い
  94. 94. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. マスターマテリアル構築の基本方針
  95. 95. アセット管理 • なるべく汎用性が高い • なるべくシンプルでわかりやすい • なるべくメンテナンスが楽 • なるべく処理負荷に優しい ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  96. 96. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 根幹は1人が整備&管理するのがやっぱり良い メンテナンスについて
  97. 97. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Static Switch Parameterを使いたかった 当初は使っていたが、分岐を変えると別シェーダーに なりファイルサイズ増大に繋がったため全て撤廃 スイッチの切り替えは「管理者しか触らない」運用も考えたが うっかり触ってしまうケースを懸念して断念した シンプルさとメンテナンス性について
  98. 98. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ブレンドモードの変更はマテリアルインスタンス側で マテリアルプロパティオーバーライドで上書いて 上書いたものだけは孫インスタンスで利用する 別シェーダー扱いになるので管理者のみ行うルール こちらは設定場所が離れていて分かりやすいのでアリとした シンプルさとメンテナンス性について アルファ 子 加算 孫 孫子
  99. 99. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • PS4実機上で処理負荷をざっと計測して マスターマテリアル構築時に判断材料にした ※具体的なことは後述 処理負荷について
  100. 100. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. エフェクトアセットの命名規則
  101. 101. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • テクスチャの場合‥ かなりガチガチに決めている 作成者 カテゴリ 内容 補足 htx_fir_8x4_00 林作成 テクスチャ 炎 8x4パターン 00番 htx_smk_02n 林作成 テクスチャ 煙 02番のノーマルマップ 連番
  102. 102. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル / マテリアルインスタンスの場合‥ かなりガチガチに決めている 作成者 カテゴリ 内容 連番 hmi_smk_8x4_fs02a 林作成 マテリアルインスタンス 煙 8x4パターン フレネル付 ソフトパーティクル付 02番 アルファ合成 f (フレネル) / s (ソフトパーティクル) / a (アルファ) / k (加算) 機能 合成
  103. 103. アセット管理 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ParticleSystemの場合‥ かなりガチガチに決めている V カテゴリ 内容A vp_aaa_hit1 プレイヤーの 技「AAA」のヒットエフェクト 1番 ve_bbb_ccc0 敵「BBB」の技「CCC」のエフェクト 0番 内容B 連番
  104. 104. ア セ ッ ト 管 理 で の 工 夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  105. 105. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. コンテンツブラウザ上でマテリアルやパーティクルの アセット名とサムネイルでは中身が判断つきにくい でもエクセルやWikiで一覧を作るのも大変だし スタッフがそれを確認しながら作業するのも大変なので‥
  106. 106. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアルとマテリアルインスタンスに説明文を記述 できるように拡張してもらった コンテンツブラウザ上でポップアップ表示される タグ付け
  107. 107. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • パーティクルにもタグ付けの機能を追加してもらった 説明文、担当者、カテゴリ、属性、進捗状況など コンテンツブラウザ上でポップアップ表示される タグ付け
  108. 108. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • パーティクルシステムを検索する専用のツール エフェクトアセットサーチャー
  109. 109. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • タグの内容や使用モジュールで検索が可能 設定に注意が必要なモジュールを検索したりできる • エフェクトのプレビューも可能 プレビューでのポストプロセスの設定変更も可能 • ツール上からの設定変更が可能 エフェクトアセットサーチャー
  110. 110. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. アセットの使用頻度を調べたいことがよくある ① 使用頻度が高いものを常駐アセットに昇格させたい ② 使用頻度が少ないものを常駐から外したい ③ 全く使用されていないものを削除したい ‥1つ1つリファレンスビューワで確認する?
  111. 111. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • セッションフロントエンドで検索可能にしてもらった 参照数0のアセットのリストアップ 行末に参照数を付与してリストアップ 使用頻度の検索
  112. 112. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 似たアセットがあちこちで生まれてしまう それらを統合する場合‥
  113. 113. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 同じようなテクスチャを一覧して統合したい場合は ローカルコレクションに登録して作業すると快適 似た絵柄の一覧
  114. 114. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ちなみにアセット統合時に利用する 「リファレンスの置換」は マテリアルとマテリアルインスタンスの置換も可能
  115. 115. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 大量にあるテクスチャやマテリアルの設定を 一括変更したい場合がある
  116. 116. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • テクスチャの基本的な設定の漏れに関しては たまにプロパティマトリクスで調べて一括変更する マテリアルは昔は使えたが今は使えない模様 設定の一括変更
  117. 117. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアルの内部に対して検索をかけ、ノードの設定 を一括で変更するコマンドレットを作成してもらった 実行ファイルで直接アセットデータを書き換える 例1:TextureSamplarノードのSamplarTypeを TC_GrayscaleからTC_Alphaに一括変更する 例2:メインマテリアルノードの設定を一括変更 設定の一括変更
  118. 118. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 開発が進むにつれ気軽に一括変換できなくなった ※意図しない設定でエフェクトが調整されているため なので今後は検索して重要な設定の漏れがあるものを リストアップだけして手動で変更する方向で検討 設定の一括変更
  119. 119. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 巨大なサイズのテクスチャはサイズマップで調べる LOD Biasは反映されないがMaximum Texture Sizeは反映される 巨大なテクスチャの検出
  120. 120. アセット管理での工夫 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 背景班のアセットを使用したい場合にルールを設けた ① 事前に連絡する ② 基本的にはコピーはしない ③ 共有コレクションに登録する • エフェクトのアセットの削除やリダイレクタ修正で 他の班のアセットに更新がかかる場合は事前確認する 他セクション間でのやり取り
  121. 121. フ ァ イ ル サ イ ズ の 計 測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  122. 122. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. PS4向けにクック済みのアセットのファイルサイズを計測
  123. 123. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. クックとは 指定プラットフォーム向けに アセットをフォーマット変換する行為 デプロイとは データを開発機にコピーしたりなどの 各プラットフォームで動かすこととその準備 By Epic 篠山さん
  124. 124. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 開発途中から毎晩自動でクック • ログのテキストでクック後のアセットが一覧できる • マクロで集計しやすい形に整形して簡易的に確認 秀丸マクロとExelのVBAマクロを併用した のちに背景班ではPythonスクリプトを用意 ナイトリークック
  125. 125. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • クックサイズをグラフで確認できるウェブページが プロジェクトのHP内に用意された 各パートごとのファイルサイズが一目で分かる 日々の推移も確認できる こちらでデータの総容量を確認していた ナイトリークックの自動集計ページ
  126. 126. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • クック後のファイルサイズを調べるだけなら 実機は必要無いので手軽に可能 専用マップを作ってUnreal Frontendでクック • 少し条件を変えてすぐに再クックするなら5~15分 指定フォルダ内のファイルを検索してファイルサイズ情報も 込みでリストアップ、CSVで出力するツールを利用 手動でのクック
  127. 127. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 各アセットをクックして判明したこと
  128. 128. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ※sRGB = ON UE4.13で計測PS4向けにクック後のテクスチャ(KiB)
  129. 129. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ※sRGB = ON GrayscaleはsRGBがONだとPS4でもXboxOneでも4チャンネル扱い VectorDisplacementはアルファチャンネル無しでも4チャンネル扱い UE4.13で計測PS4向けにクック後のテクスチャ(KiB)
  130. 130. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. UE4.13で計測PS4向けにクック後のテクスチャ(KiB)
  131. 131. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. LOD Biasはファイルサイズに反映されるがマイナスの値は反映されない LOD BiasはNoMipmap設定時には当然ながら反映されない MaximumTextureSizeはNoMipmap設定時でも反映される LOD BiasとMaximumTextureSizeは併用しても反映される UE4.13で計測PS4向けにクック後のテクスチャ(KiB)
  132. 132. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. UE4.13で計測PS4向けにクック後のメッシュ(KiB)
  133. 133. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. UE4.13で計測PS4向けにクック後のメッシュ(KiB)
  134. 134. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. インポート設定のAuto Generate Collisionと Generate Lightmap UVsがONだと約1.7倍のサイズになる UE4.13で計測PS4向けにクック後のメッシュ(KiB)
  135. 135. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 条件:EmissiveとOpacityにBC4のテクスチャ2枚 頂点カラーとパーティクルカラーを混ぜたもの テクスチャはUVのタイリング数を指定可能 UE4.13で計測PS4向けにクック後のマテリアル(KiB)
  136. 136. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. UE4.13で計測PS4向けにクック後のマテリアル(KiB)
  137. 137. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 何がクックされるのか?
  138. 138. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル内で孤立した未使用のノード群 (テクスチャも含まれる) クック時に含まれてしまう要素
  139. 139. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル内のテクスチャ系のパラメータ化した ノードでデフォルトで設定しているテクスチャ • メッシュにデフォルトで設定しているマテリアル クック時に含まれてしまう要素
  140. 140. • マテリアルやマテリアルインスタンスのエディタで プレビュー用に指定しているスタティックメッシュ • マテリアル関数のInputやOutputノードに プレビュー用に接続しているテクスチャ ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. クック時に含まれてしまう要素
  141. 141. ファイルサイズの計測 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Cascade上で非表示状態にしているエミッターが 参照しているメッシュ/マテリアル/テクスチャ クック時に含まれてしまう要素
  142. 142. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  143. 143. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. UE4エディタ上でのチェックについて
  144. 144. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. パフォーマンスで指標になるのは シェーダー複雑度、パーティクル数、エミッター数や パーティクルに内包したライトの数や範囲
  145. 145. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. エフェクトのチェックが容易になるように エフェクト台座(Pawn)を作ってもらった
  146. 146. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • エフェクトを1つ指定してプレイ時に繰り返し再生する エフェクト台座
  147. 147. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 台座に近付くかレベル開始時に再生 • エフェクトのオフセットの指定も可能 • 台座を中心に周回させる機能 周回速度の指定が可能 周回方向にエフェクトの向きを 合わせる設定もある • チェックで非常に重宝 エフェクト台座
  148. 148. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. エフェクトを切り替えてのチェックが容易になるように エフェクト切り替え表示アクターを作ってもらった
  149. 149. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • エフェクトをいくつでも登録することが可能 ゲームプレイ時にキーボードショートカットで エフェクトを切り替えて再生できる エフェクト切り替え表示アクター
  150. 150. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 矢印キー左右でエフェクトの切り替え&再生 スペースキーで現在のエフェクトを再度再生 • 今どのエフェクトが表示されているかはログに表示 • エフェクトをXY軸方向に 好きな数だけ並べられる 指定範囲で等間隔に配置する エフェクト切り替え表示アクター
  151. 151. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. ライティング環境の中でのエフェクトのチェックには 背景班が用意した時間帯を切り替えられるレベルで確認
  152. 152. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 朝から夜の10個の時間帯のライティング環境を設定 したサブレベルをショートカットで切り替えられる • PostProcessVoumeアクターの設定もプロジェクトで 標準的な設定にしてもらう • 暗いシーン、明るいシーンどちらでも破綻のない 見た目になっているかチェックする 全時間帯が切り替えられるレベル
  153. 153. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 実機上でのチェックについて
  154. 154. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • エフェクトチーム内の共有ブースでチェック • CPU / GPU の処理負荷は実機で計測
  155. 155. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 最低限の構成のレベルを用意 床と平行光源1つとエフェクト切り替え表示アクター • 余計な処理を全てOFF • 垂直同期をOFF FPSの天井を上げる r.VSync 0 t.maxFPS 120 処理負荷の計測の流れ
  156. 156. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • オーソドックスなテクスチャとマテリアルのセットを 5種類用意して、それぞれをエミッターに登録した シンプルな標準想定のエフェクトを基準として用意 • さらに一部の条件を色々と変えたエフェクトを用意 • それらをエフェクト切り替え表示アクターに登録 処理負荷の計測の流れ
  157. 157. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • エフェクト1個では差が僅かで計測しづらいため 単体と25個など同時再生数を変えてそれぞれ計測 • Stat Unitの値でざっくりとチェック バージョンアップごとにはやってられないが どこかのタイミングで一度行っておくと参考になる 処理負荷の計測の流れ
  158. 158. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 基本構成(Unlit) • DefaultLit • 片面と両面 • Fresnelあり • ソフトパーティクルあり • World Position Offsetあり • Powerを沢山入れたもの • 極座標を沢山入れたもの • DynamicParameter入り マテリアル関連での計測結果 UE4.9の頃
  159. 159. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 基本構成(Unlit) • DefaultLit • 片面と両面 • Fresnelあり • ソフトパーティクルあり • World Position Offsetあり • Powerを沢山入れたもの • 極座標を沢山入れたもの • DynamicParameter入り - CPU/GPU上昇 差は無し GPU微上昇 GPU上昇 差はほぼ無し GPU微上昇 GPUかなり上昇 GPUかなり上昇 UE4.9の頃マテリアル関連での計測結果 UE4.13で差は無し
  160. 160. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. これらを踏まえてマスターマテリアルの構成の参考にした
  161. 161. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 最初に班内のメンバーに日替わりでクックしてもらい Unreal Frontendを覚えてもらった • プログラマに負荷チェックのアドバイスを 実機プレイしながらレクチャーしてもらった • テストはDevelopersフォルダで行ってもらう 実機に乗らない実験データや途中段階のデータも キリの良いタイミングでDevelopersに移してもらう その他 ちょっとしたこと
  162. 162. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 特別に重たい表現は描画エンジニアに相談 例えばParallax Occlusionは処理負荷を実機で計測 して班内に周知し、使用場面を限定してもらう (大技で画面に1個だけ出る場合ならOKのような) 画面内での描画面積にも気を付けてもらう その他 ちょっとしたこと
  163. 163. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 描画に不具合が起こった場合はRenderDocで キャプチャーして描画エンジニアに提出 シンプルなのでアーティストでも使いやすい キャプチャーデータを 提出時には描画のどの タイミングで起こって いるか、大まかに見る くらいはしている その他 ちょっとしたこと
  164. 164. チェック環境 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • こんなXYZ三軸メッシュモデルを用意しておくと スプライトの挙動やアタッチのチェック等で大変便利 その他 ちょっとしたこと
  165. 165. ©2016 SQUARE ENIX CO., LTD. All Rights Reserved. 補足事項 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  166. 166. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  167. 167. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • なるべく必要最小限にする前提で ゲーム中に表示して許せる解像度にする • 1024 x 1024 を上限の目安としてルール化 • どうしても大きいものが欲しい場合もある (広範囲のデカール、SubUVテクスチャ) 解像度
  168. 168. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 単色で良い場合は 1 x 1 で用意 • グラデーションの場合は 1ドット幅で用意 解像度
  169. 169. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 可能なものは 1/4カット、1/2カットで用意 Tilling MethodはMirrorにしておく マスターマテリアルでは全てのテクスチャをタイリング可能にしておく 解像度
  170. 170. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ミップマップの仕様を理解しておく必要がある テクセル密度が高いほどMipLevelが上がる • つまりカメラからの距離だけでなく パーティクルのスケーリングや UVのタイリング数によってMipLevelが変化する 当初は理解していなかったため、GPUパーティクル用に 解像度の低いテクスチャを用意したりしていた‥ ミップマップ
  171. 171. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • カットシーンでもカメラから少し離れてるなら 512 x 512 で十分だったりする • アンコウさん(@dgtanaka)のブログ記事が分かり易い ミップマップ 『MipMapを可視化しよう』 http://qiita.com/dgtanaka/items/2ec0fd88236daa5c3cc7
  172. 172. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ミップレベルを可視化するマテリアルの紹介 1 ミップマップ
  173. 173. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ミップレベルを可視化するマテリアルの紹介 2 ミップマップ
  174. 174. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 基本的にはNoMipmapsにはしない MipMapが生成されない分ファイルサイズは減るが 常に最大解像度のテクスチャがメモリに乗るため またエイリアシングが目立つ Mip Gen Settings
  175. 175. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル内でタイリングしてスケール調整する例 微調整できるのでスタッフには好まれているが‥ MipLevelが上がるので可能ならやめた方が無難 やるなら専用にNoMipmaps設定にした方が良いかも U1, V1U2, V2 ※Clamp設定にする必要あり Mip Gen Settings
  176. 176. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Effectsで統一するルール 一括で内部設定を変えることができる アセットの種類を特定することができる Texture Group
  177. 177. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • カラー(DXT1)はsRGBをON / モノクロ(BC4)はOFF モノクロテクスチャはマテリアル内で累乗している また不透明度も累乗しないと違和感が出る問題がある なので不透明度もマテリアル内で累乗するよう対応 ガンマ
  178. 178. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Powerで2.2乗せずMultiplyでの2乗で良しとした 2.2乗 2乗 2.2乗 2乗 ガンマ
  179. 179. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 頂点カラーもリニアな値なので2乗する ガンマ
  180. 180. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 一目で分かるようマテリアル関数化 ガンマ
  181. 181. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 2.2乗から2乗へ移行する際はテクスチャをPhotoshop のレベル補正で中間ポイント0.91あたりで調整する ガンマ
  182. 182. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • すると調整前のテクスチャに2.2乗した結果と 並べてみてほぼ分からないくらいに一致する 調整済み 2.2乗 2乗 ガンマ
  183. 183. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 圧縮設定をBC7はVectorDisplacementmapの 代わりに使用して大幅にファイルサイズが減らせる? Compression Settings
  184. 184. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • テクスチャの最大サイズはLOD Biasでは無く Maximum Texture Sizeで指定した方が良い NoMipamapでも反映される / サイズマップにも反映される Maximum Texture Size
  185. 185. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 特に意図が無ければ基本的にはWrapから変えない 同じ絵柄でWrapとClamp両方用意するのは避けたい X(Y)-axis Tiling Method
  186. 186. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 国際基準のsRGB IEC61966-2.1に対応したので Photoshopと一致させるにはチェックをOFFにする Use Legacy Gamma
  187. 187. テクスチャ ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 基本的にONにはしない 全てのMipLevelをメモリ上に乗せてしまうから • ただしどのMipLevelも使用頻度が高いならONもアリ また炎のようにディティールがあるものも検討対象 一発目のロード時間を念頭に入れつつ設定する Never Stream
  188. 188. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  189. 189. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ONとOFFが混在すると描画順に影響が出る なので基本的には統一した方が良い これによってマテリアルの運用に影響が出る Separate Translucency Separate Translucency OFF 被 写 界 深 度 Separate Translucency ON 不 透 明
  190. 190. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 基本的にOFFにする場合 ゲーム中に被写界深度があり、影響を受ける ただし影響を受けたくない場合にSeparate ONの 汎用マテリアルを別途用意&管理する必要がある プログラマにデフォルト設定をOFFにかえてもらった • 基本的にONにする場合 ボケを擬似的に表現するマスターマテリアルを 別途用意&管理が必要? Separate Translucency 採用
  191. 191. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 必要最小限の設定にしたい しかし汎用マテリアルには 最初から設定しておきたい ので‥ Particle Sprites Beam Trails Mesh Particles の3点はチェックONで運用 Static Lightingも入れといてOKかも Usage
  192. 192. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • プログラマにマテリアルの詳細パネル内に 専用の項目を追加してもらった チェックボックスをONにするだけなのでとても楽 例:エミッシブカラーの値の露出補正への対策など 独自の設定項目
  193. 193. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Divideノード使用時にはBポートに0が入る可能性を 考慮して0.0001をAddするなど対策を行う 実際に描画の不具合の原因だったことが何度かあった 0除算対策 Addの方が高速で、厳密にやるならMaxやMinやClampが良い(篠山さん)
  194. 194. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 複数のTexture Parameterにマテリアルインスタンス 内で同一テクスチャを複数指定した場合、その数だけ サンプリングされてしまう 同一テクスチャの複数回の参照
  195. 195. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • テクスチャのSamplerTypeがAlphaの場合は Rチャンネルの値を使用するようにする SamplerType周りの注意点 プラットフォームで赤く表示される可能性あり / R を使用するのが無難
  196. 196. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 入力する引数が一致しているのはOK 基本的に引数が 多いのはOK 少ないのはNG データ型周りの注意点
  197. 197. • 入力する引数が一致しているのはOK 基本的に引数が 多いのはOK 少ないのはNG マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. データ型周りの注意点
  198. 198. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ただし注意が必要な場合もある データ型周りの注意点
  199. 199. • ただし注意が必要な場合もある マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. データ型周りの注意点
  200. 200. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • DynamicParameterノードの利用先 定番はUV周りの設定? ここで吸収することでマテリアルインスタンスの数を 一気に減らせるので何気に重要 • ParticleColorノードの色以外への利用先 EmissiveColorが固定値で良い場合に活用できる 例えば屈折マテリアルでは屈折の強さに使用している 工夫しがいのある部分
  201. 201. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • ParticleRandomノードの利用 GPUパーティクルに限定されるものの パーティクルごとに0~1のランダムな値を与えられる UVスクロールの初期値ランダムやSubUVの 開始パターンのランダムに利用するなどが考えられる 工夫しがいのある部分
  202. 202. マテリアル ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Static Component Mask Parameterノードの利用 BC7を使用して4チャンネルを使い分ける構成ができる ただし切り替えで別シェーダーになるため注意が必要 工夫しがいのある部分
  203. 203. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  204. 204. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 汎用アセットのマテリアル、マテリアルインスタン ス、 マテリアル関数にはしっかりと説明文を記入する コンテンツブラウザでポップアップ表示される 説明文の記載
  205. 205. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル関数のInput / Outputノードには 説明文を記載する 説明文の記載
  206. 206. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル関数は検索しやすいようカテゴリを設定 マテリアル関数のカテゴリの設定
  207. 207. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル関数のInput / Outputノードには 適切なデフォルト値を入力して Use Preview Value as DefaultをONにする デフォルト値の設定
  208. 208. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • マテリアル内でパラメータ化したノードや DynamicParameterに適切なデフォルト値を入力する テクスチャの場合クックされることに注意する デフォルト値の設定
  209. 209. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • コンテンツブラウザ上で何のマテリアルか分かるよう テクスチャノードにアイコン画像のテクスチャを 指定してサムネイル化する工夫をした デフォルト値の設定
  210. 210. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • パラメータには可能なものは値に制限を付ける インスタンス側でスライドバーでの確認が容易になり マイナス値など想定外の値で使用されるのも防げる そうすると後のメンテナンスが楽になる パラメータの値の制限
  211. 211. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 親マテリアルを差し替えた時パラメータ名が同じだと 設定した値を引き継いでくれるので、パラメータ名は シンプルでストレートなものが良いが、その前提で‥ パラメータ名の設定
  212. 212. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • Group名の並び順を指定できないので基本要素の 「1 Emissive」「2 Opacity」「3 Normal」など 一部だけ先頭に連番を付けた パラメータ名の設定
  213. 213. マテリアルの利便性向上 ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • UVは先に速度を与えてからタイリングさせると良い タイリング数を変えてもスクロール速度が変わらないので設定が楽 UV周りの計算順
  214. 214. 最 後 に ©2017 SQUARE ENIX CO., LTD. All Rights Reserved.
  215. 215. 最後に ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. • 開発が進むと大きく変更するのが厳しくなるので 最初に考えられることはできるだけ考えるのが良い • 初めてだとUE4の機能や仕様の把握、実機で出すと どうなのかという検証などにとても労力がかかった なので積極的に情報交換した方が良いように思う • 今後のDeepDiveもとても楽しみ!
  216. 216. 最後に ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 長時間お付き合いくださりありがとうございました! 駆け足でお見苦しかったらすみません 後日ゆっくりスライドを見て頂けたらと思います
  217. 217. 最後に ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. 何かご意見やご質問等ありましたらこちらまで お気軽にメールください! hatakeru@square-enix.com
  218. 218. ご清聴ありがとうございました! ©2017 SQUARE ENIX CO., LTD. All Rights Reserved. Unreal Engine 4 は Epic Games 社の商標または登録商標です。 PlayStationは株式会社ソニー・インタラクティブエンタテインメントの商標または登録商標です。 その他掲載されている会社名、商品名は、各社の商標または登録商標です。

Notas del editor

  • この図の場合は6つですが、派手なエフェクトになると20~30個になったりします。
  • 1つのエミッターには1つマテリアルを指定し、そのマテリアルが貼り付けられたパーティクルを表示します。

    なので1つのエフェクトに20個のエミッターがあれば、マテリアルもしくはマテリアルインスタンスを20個使用していることになります。

    つまり、エフェクトは多くのマテリアルを使用して表現します。
  • この図の場合、エミッシブカラー用のテクスチャAと、オパシティ用のテクスチャBの2枚を使用しています。

    「テクスチャAにアルファチャンネルを持たせてそのままオパシティに使用したらいいじゃん」という方もいらっしゃると思いますが‥
  • エフェクトのテクスチャはそもそもモノクロで十分な場合が多いので、1チャンネルのモノクロテクスチャをエミッシブとオパシティそれぞれ自由に組み合わせられるようにした方が表現のバリエーションは広がります。

    もちろん、テクスチャのサンプリング数を抑えるためにアルファチャンネルで運用するのが有効な場合もあると思います。
    このあたりは初期に検討しないといけない課題の1つになると思います。
  • 他にも、テクスチャのUVを歪ませるために別のテクスチャを使用したりもします。

    この図はテクスチャAを歪ませるためにテクスチャCを使っていますが、テクスチャBを歪ませたい場合や、テクスチャAとB両方歪ませたい場合もあります。
  • また、エフェクトが千切れて消えていく表現をするために、オパシティに千切れ用の別のテクスチャを指定したりもします。

    この時、そのままテクスチャDの形状で削っていきたい場合もあれば、元々のテクスチャBの形状でも削っていきたい場合もあります。
  • ここでテクスチャについてまとめると、1つのマテリアルに対してテクスチャを複数枚使い、それが2枚の場合もあれば、もっと沢山使う場合もあります。

    もし1つのエフェクトに20個のマテリアルを使用していたなら、テクスチャは4、50枚は使っていることになります。
  • エミッターAでマテリアルインスタンスを指定していたら、その親となるマスターマテリアルと、マスターマテリアルでデフォルト指定しているテクスチャも参照していますし、マテリアルインスタンス側で差し替えたテクスチャも参照しています。これら全てが参照されていることになります。

    つまり、クックすると、これら全てのアセットがクックされることになるので、注意が必要です。
  • パーティクルは大きく分けると、スプライトパーティクルとメッシュパーティクルに分かれます。
    これはざっくり言えば、マテリアルをそのまま板に貼り付けて表示するか、好きなスタティックメッシュを指定して貼り付けるかだけの違いです。

    (他にもビームやトレイルなど特殊なものもありますが、ここでは例外として割愛します)

    この講演では、板に貼り付けて表示するパーティクルを、「スプライトパーティクル」と呼称します。
  • メッシュパーティクルの場合、指定したメッシュに元々貼られているマテリアルをそのまま使うこともできますし、別のマテリアルで上書くことも可能です。

    これはとても便利で強力な機能です。
    エフェクトエディタである「カスケード」上で、自由にメッシュとマテリアルを組み合わせることができます。
  • これがもしもオーバーライドできない仕様だったら、全く同じ形状のメッシュをマテリアルの数分、用意せざるを得なかったと思います。

    (なかった時のことは想像したくないですね‥)
  • エミッターBで指定したメッシュが、元々適用しているマテリアルとテクスチャも参照されていますし、オーバーライドしたマテリアルがマテリアルインスタンスだった場合、その親となるマスターマテリアルが参照しているものと、マテリアルインスタンスが参照しているものが全てクックされることになります。 「何が一緒にクックされるか」については、後ほどあらためてお話します。
  • つまり、たったエミッター6つで構成されたシンプルなエフェクトでも、これだけのアセットを組み合せて作成したりします。

    実際にはもっと少なかったり増えたりしますが、1つのエフェクトで沢山のアセットを使っているということがお分かり頂けたかと思います。
  • エフェクトを構成するための汎用アセットは、図のように汎用的なメッシュが大量にあり、汎用的なマスターマテリアルやマテリアルインスタンスが大量にあり、汎用テクスチャが大量にあるといった感じになります。
  • このうち、スタティックメッシュに関しては、先程お話したようにエフェクト側からオーバーライド可能なので、必要な数だけを用意するので事足ります。
  • しかし問題はマテリアルとテクスチャの組み合わせの部分です。

    マテリアルインスタンスは、パラメータを変更したいバリエーションの数だけ用意しないといけません。
    例えばテクスチャを自由に差し替えるなら、差し替える数だけマテリアルインスタンスを用意する必要があります。
  • 図にするとこんな感じです。
    ものすごく乱暴に言えば、マスターマテリアルが20種類で汎用テクスチャが100種類あれば、マテリアルインスタンスを2000個用意するといったイメージになります。
    しかも実際にはUVのタイリング数のようなパラメータ違いでさらに数が増えます。

    これらの組み合わせを汎用マテリアルインスタンスとして最初からある程度用意しておくのか、それともマスターマテリアルだけ用意して、あとは作業スタッフが必要に応じてその都度マテリアルインスタンスを作成するのに任せるのかで、運用スタイルが変わってくると思います。
    マテリアルインスタンスのファイルサイズは極小なので、あちこちで同じ内容のマテリアルインスタンスが生まれようとも気にせず運用するのもありかも知れません。
    私の場合は、最初にある程度必要だろうと思うものを用意しました。
  • 今のはマテリアルインスタンスのお話ですが、マスターマテリアル自体も結構な数が必要でした。
  • こちらは、UE4.13であらためてテクスチャのサイズを計測してみたものになります。

    (BC7は計測していませんが、DXT5と同じサイズではないかと思います)
  • こちらはエフェクトの汎用的なマテリアルを、UE4.13であらためて計測してみたものです。
    100KBから500KB近いものまであります。

    マテリアルインスタンスとマテリアル関数は、ファイルサイズ面では問題になっていません。
  • こちらはエフェクトの汎用的なスタティックメッシュを、UE4.13であらためて計測してみたものです。

    エフェクトで使用するメッシュは、せいぜい数百ポリゴン程度のものが大半なので、ファイルサイズ面ではさほどネックにはなっていません。
  • 図にするとこのようなイメージです。
    メモリには汎用的なテクスチャ・メッシュ・マテリアルを常駐させておいて‥

    レベルに依存せずいつでも表示される可能性があるエフェクトは常駐アセットで作成して、レベルに紐付くものは固有アセットの併用もよしとします。
    ザコ敵はレベルに配置されるのでレベルに紐付きますが、色んなレベルで登場する可能性があるのでなるべく常駐アセットで賄います。

    しかし本タイトルでの事例ではこんな理想的にはいっておらず‥
  • 実際には水色の部分のように、プレイヤーの汎用技などにも固有アセットが多くなりました。特殊な表現が多いためです。
    しかしプレイヤーはゲーム中にずっと表示されるので、プレイヤーに紐付くアセットはそのまま常駐されます。
    なので結果的に、「汎用的ではないけれども常駐される固有アセット」となりました。
  • 以上がエフェクトアセットの概要になります。

    これらを念頭におきながら、どうアセットを運用するかを考えていきました。
  • ここからは、UE4で開発したあるPS4タイトルの事例のお話になります。
  • ちょっと特殊なケースになります。
    大規模プロジェクトのチーム構成、アセット構成なのですが、ゲーム全体ボリュームは小さめになります。

    なのでアセットの総数や総容量の面ではあまり参考にならないかも知れません。
  • ひとつ注意があり、開発時は最終的にUE4のバージョンは4.12でしたが、今回UE4.13で再計測しています。
  • エフェクトの総アセット数は約3000となりました。

    緑色のグラフが常駐指定したアセットで、汎用的なアセットの他に、セーブポイントとか、敵を倒した時の消滅エフェクトなど汎用的なデータが含まれています。
    水色のグラフがプレイヤー専用に作られたアセットです。プレイヤーは汎用アセットだけで作れると理想ですが、賄えていないことが分かります。

    そして茶色のグラフが固有アセットで、こちらも数としてはかなりの量を作っています。
    とは言え、問題はアセット数ではなくファイルサイズの方です。
  • 総ファルサイズは約500メガで、テクスチャが占めているだけでなく、予想以上にマテリアルが大きく占めていました。

    水色のプレイヤー専用アセットでは、マテリアルが34メガと、結構、容量を食っています。

    茶色の固有アセットでは、テクスチャもマテリアルもかなりの容量を占めています。
    メッシュも44メガとそこそこの容量になっているのは、キャラクターや武器、背景のギミックやちょっとしたオブジェクトを発光させたり消滅させたりするためにエフェクト用にメッシュを別途用意したのですが、それらが1つ1MBから4MBほどになっていました。

    マテリアルインスタンスやマテリアル関数は当然ながらファイルサイズの観点では全く問題になっていません。

    (パートごとでは、レベル依存のものが200MB、プレイヤーが80MB、敵が50MBといった感じです)
  • ここから具体的なアセット管理のお話に入ります。
  • まず、エフェクトで扱う主なアセットの種類はこのような感じです。
    「マテリアル関連」というのは、マテリアルインスタンス、マテリアル関数、マテリアルパラメータコレクション、デカールマテリアルなどがあります。
    「パーティクルシステム」は、UE4標準のエフェクトツールである「カスケード」を使って作成したエフェクトデータのことです。
    本スライド中に「パーティクルシステム」と言ったらり「エフェクト」と言ったりと表記揺れしていますが、どちらもエフェクトデータのことだと思ってください。

    (スケルタルメッシュは基本的に使用していません。理由はパーティクルシステムで直接扱えないためです。
     なるべくパーティクルシステムで1つのエフェクトを完結したいというのがエフェクト班での基本方針になっています)
  • プロジェクト全体のフォルダ構成の中で、エフェクトに関するアセットは全てエフェクトフォルダ内で一元管理しています。

    つまり、各キャラクターや各レベルのフォルダ内にそれぞれエフェクトフォルダがある、といった構成にはしていません。
  • エフェクトフォルダ以下には各パートごとのフォルダがありますが、大きく分けるとプレイヤーやエネミーのようにレベルに紐付かないものと、レベルに紐付くものとに分かれます。

    レベルに紐付くものも、当初は背景エフェクト、ギミックエフェクト、カットシーンエフェクトをそれぞれフォルダを分けて管理していましたが、途中でレベルに紐付くものはLevelフォルダ内に集約させました。
    その方がレベルごとのファイルサイズの集計がしやすいからです。
    (ただしボスに関しては固まっていた方が管理しやすいのでLevelフォルダ内では無くEnemyフォルダ内で管理しています)
  • それから、メモリに常駐させるアセットは「コモン」フォルダで管理して、常駐はさせないものの汎用的なアセットは「ユースフル」フォルダで管理しています。

    コモンフォルダは書き換え権限を私だけもらって管理しています。 欲しいアセットの要望を受けたり、ヒアリングしたりしてその都度反映していきます。

    「ユースフルフォルダ」は、似たような固有アセットがどんどん増えないようにするために用意しているフォルダで、誰でもアセットを追加可能です。
  • プレイヤーやエネミーやレベル内など、各フォルダで固有に作成されているアセットでも、汎用的に思えたらユースフルフォルダに移動しています。
  • 「コモン」フォルダで使用頻度が低いものは「ユースフル」フォルダへ降格し、逆に「ユースフル」フォルダで使用頻度が高いものは「コモン」フォルダへ昇格させたりしています。

    これから詳しくお話するのは、この「コモン」フォルダに入る常駐アセットについてになります。
  • 常駐アセットはさらに図のようなサブフォルダにアセットを分けています。

    特にマテリアルインスタンスは数が多くなるので、用途別にフォルダを分けました。

    (この他にマテリアル関数フォルダもあります)
  • エフェクトのマテリアルで扱う主な要素はこのような感じです。
    1つ1つの説明は後に取り上げています。

    また、ここでは基本的なものを抜き出しただけで、他にも屈折させたい場合があったり、千切れさせたい場合があったりと、まだまだ要素はあります。
  • マスターマテリアルが組み合わせ爆発を起こします。

    大雑把に言えば、この図のように10種類の要素の組み合わせ分を全て用意すると、マスターマテリアルが1024種類に及んでしまいます。

    ※ParColはParticleColor、VerColはVertexColor、DynParamはDynamicParameter、ソフトはソフトパーティクル(DepthFade)、フェードはニアフェードの略
  • なので、何かを諦めて要素を排除するか、または全てにその要素を含めてしまうなどして、いかに組み合わせを抑えるかという話になってきます。
    この図の場合は、4つの要素を統一することで、1024種類から64種類まで一気に減りました。
  • 具体的にどういった感じで取捨選択していったか。
  • まずはエフェクトのマテリアルに必要な基本設定から順に見ていきます。

    要するにメインマテリアルノードの設定についてです。
  • まずブレンドモードが、アルファ合成か加算合成かについて。

    こちらに関しては、どちらも使うケースがあります。

    ブレンドモードだと他にオペイクやマスクドを、岩などで使う場面がありますが、例外になるのでここでは省きます。
  • 次にシェーディングモデル。
    端的に言えばライティングありか無しかです。

    こちらは、どちらも使うケースはあると言えばあるのですが、基本的に無しでいきました。

    半透明でライティングを使うものに煙がありますが、普段は使用しなかったので例外になります。
  • そして両面処理。片面か両面か。

    スプライトパーティクルは片面でも両面でもどちらでもOKですが、メッシュパーティクルの場合、大抵は両面を使用します。

    例えば左の図のようなカップ形状だと、表も裏も見えてくれないと困りますし、右の図のように平面的なモデルであっても、片面だと後ろから見えなくなってしまうので両面の必要があります。
    このように、エフェクトの場合、片面を使う場面は、案外かなり限られています。
  • Separate Translucencyを利用するかどうかについて。
    半透明マテリアルでこちらをONにすると、専用のバッファに描画され、被写界深度の後にシーンに合成されるので被写界深度がかかりません。
    また、専用バッファに描画されるためバッファの解像度を下げることで、いわゆる「縮小バッファ」としての利用ができます。

    こちらに関してはゲーム中に被写界深度の影響をエフェクトに与えるために基本的にOFFにしました。

    ただしカットシーンで被写界深度の影響を受けたくない一部のエフェクトは例外として使用しました。
    (スライド最後の「補足事項」で少し補足しています)
  • レスポシブAAを利用するかどうかについて。
    テンポラル・アンチエイリアシングを利用している場合に、半透明のパーティクルが背景に溶け込んでしまわないようマスクする機能です。

    こちらについては、そもそもテンポラルAAを使っていないのでOFFにしています。
  • マテリアルアトリビュートを使用するかどうかについて。

    こちらは拡張やメンテナンス面で便利だとは思いましたが、使いませんでした。
    使わなかった理由がいくつかありまずが、各場面ごとに必要な固有のマテリアルをエフェクトチーム全員が作成するため、マテリアルアトリビュートの使用を徹底するのが難しそうだと感じたのが大きな理由になります。
    かといってマテリアルアトリビュートを使うもの、使わないもので混在させるのも、混乱を招きそうだと考えました。
  • 次に、エフェクトのマテリアルに必要な機能について

    こちらは、マテリアル内のノード構成をどうするかについてになります。
  • パーティクルカラーノードを使用するかどうか。
    こちらをマテリアル内で使用すると、エフェクト側で指定した色を与えることができます。

    基本的に使用します。
    ほぼ全てのマスターマテリアルに含まれていて、使用していないものは一部の例外だけです。
  • 頂点カラーノードを使用するかどうか。
    こちらをマテリアル内で使用すると、メッシュに設定した頂点カラーを反映させることができます。
    主にメッシュのフチを透明にするために使用しています。

    必要無い場合も多いのですが、マスターマテリアルの数を減らすために、ほぼ全てのマスターマテリアルに含めました。
    頂点カラーを含めていないものは一部の例外だけです。
  • テクスチャサンプラーノードは当然使用しますが、カラーのテクスチャとモノクロのテクスチャを、どちらも使用するかどうかについて。

    基本的にはモノクロテクスチャを使おうというスタンスですが、カラーテクスチャが必要な場面があるので、どちらも使用します。
    ただ、非圧縮のグレースケールも使いたい時がある、BC7を使いたい時もある、といったように使いたい圧縮タイプが増えると、その対応のためにマテリアルが増えてしまうので、基本的にカラーならDXT1、モノクロならBC4の2種類でいきましょう‥というルールにしました。

    屈折のためにノーマルマップを使ったりなど例外はあります。
  • 余談になります。
    例えばエミッシブカラーやオパシティが固定値で良い場合に、固定値マテリアルを用意するかどうかです。

    こちらに関しては、マスターマテリアルの数を増やしたくなかったので、1x1ドットの真っ白テクスチャを使用するようにしました。

    ※ただし処理負荷がシビアな場合には、余計なテクスチャサンプリングを無くすために固定値マテリアルを用意した方が良いかも知れません
     参考:篠山さんの講演より
     http://www.slideshare.net/EpicGamesJapan/cedec2016-unreal-engine-4
     https://www.youtube.com/watch?v=iqYQvpTndTw
  • パーティクルサブUVは、パーティクルでテクスチャのパラパラアニメを行う、専用のノードです。
    このノードを使うと、パターンが切り替わる時にクロスフェードさせることが可能です。

    こちらは当然ながら使用します。
    ですが、パラパラアニメしない「1枚絵」のテクスチャであってもパーティクルサブUVノードを使うようにすれば、マテリアルを減らせるなあと思いました。
    ただし、この場合に何か問題があったような気がします。でも思い出せません‥

    以降、本スライドでは、パーティクルでパラパラアニメさせることを「サブUV」と呼びます。
    この後も何度か出てくるので、覚えておいて頂ければと思います。
  • テクスチャにUV周りの設定ができるような構成にするかどうか。

    タイリングに関しては、マテリアル内で使用している全てのテクスチャに対して、設定可能にしています。
    ただしスクロール速度の制御や、UVの初期値をランダムにするための構成は、マスターマテリアルに入れているものと入れていないものがあります。
    こちらについては後ほどお話しします。
  • 余談です。

    エミッター側からマテリアル全体を90度、180度、270度回転させる機能、UVを反転させる機能と、マテリアル全体のタイリング数を変えられる機能を追加してもらいました。
    これにより、マスターマテリアルのみならずマテリアルインスタンスの数も大きく減らせていると思います。
  • ダイナミックパラメーターを使うかどうかについて。
    こちらはエフェクトのエミッター側で最大4つの好きな値を入力して、それをマテリアル側で取得することが可能な機能です。
    エフェクトに特化して「動的にマテリアルの値を変えられる」「パーティクルごとに別々の値を与えられる」、この2点がサポートされているのが最大の特徴です。

    普段は必要ないのですが、UVスクロール速度をカーブエディタで制御したい場合や、UVの初期値をパーティクルごとにランダムにしたい場合に必要です。
    なので、主にメッシュパーティクル用のマスターマテリアルに組み込むようにしました。

    ダイナミックパラメーターは、スライド内でこの後も何度か出てくるので、覚えておいて頂けたらと思います。
  • デプスフェードノードを使うかどうか。
    こちらは、不透明オブジェクトへの突き刺さりを緩和する、いわゆる「ソフトパーティクル」を行うためのものです。

    全てのマスターマテリアルで使用したい‥と思うところですが、GPU負荷が上昇しますし、パーティクルのすぐ後ろに壁があったり、地面に敷いたりすると見えなくなってしまうので、使い分ける必要があります。
  • フレネルノードを使うかどうか。
    こちらは、(カメラからの視線と、メッシュの法線が正対するか直交するかで色分けできるので)輪郭を光らせたり、輪郭を透明にしたい場合に使用します。
    エフェクトの場合は輪郭を透明にしたい場合の方が多いです。

    フレネルに関しては、必要無い場合もありますし、使いたい場合もあります。
    主にメッシュパーティクルで使用しますが、スプライトパーティクルでも、ビルボードさせない場合に、正面からははっきり見えて欲しいけど横から見ると消えて欲しいような場合で使ったりもします。
  • カメラオフセットはパーティクルの位置をカメラ方向にズラす機能で、マテリアルでもWorld Position Offsetを使って実現できますし、マテリアルで行わなくても、そもそもエフェクト側にカメラオフセットの機能があります。
    ただ、GPUパーティクルではカメラオフセット機能が使えないため、最初はGPUパーティクル専用のマスターマテリアルを別途用意して、そこにカメラオフセットの構成を含めていました。

    ですが、その後にGPUパーティクルでも可能な代替となる機能を追加拡張してもらったので、マスターマテリアルには全く不要な要素になりました。
  • エフェクトチーム内では「カメラフェード」とか「(カメラ)ニアフェード」と呼んでいるもので、パーティクルがカメラに近づくとフェードアウトさせるノード構成です。

    こちらはパーティクルがカメラに近づくと、大写しになった後に突然パっと消えるのを軽減させるために欲しい場合がありますが、基本的には入れずに様子を見ました。
    どうしても欲しい場合のためにマテリアル関数だけ用意して(各スタッフが固有でマテリアルを作る際に)使ってもらっていました。

    ただし、後にエミッターでニアフェードの設定が可能なよう追加拡張してもらいました。
  • 以上のような感じで取捨選択していき、図のような必要最小限の組み合わせを決めました。

    32種類あれば最低限はカバーできるという考えです。

    ここからさらに、カラーテクスチャを諦めたり、ソフトパーティクルを諦めたりすれば、16種類、8種類と減らしていくことができると思います。
  • このまま32種類で運用するとシンプルで分かりやすいですが、DynamicParameterでUVスクロールをコントロールしたいような場合にどうしようかという問題があります。
    DynamicParameterを全てのマスターマテリアルに入れてしまうには問題と感じる点が当時にはいくつかありました。
  • そこでこのように、スプライトパーティクル用のマスターマテリアルには、フレネルとDynamicParameterは必要ないので外し、メッシュパーティクル用のマスターマテリアルには、SubUVを外してDynamicParameterを入れる‥というようにマテリアルを大きく2分しました。

    こちらをベースに、最も基本的なマスターマテリアルを用意していきました。
    ただし、ここには屈折や、テクスチャを歪ませたり千切れて消えさせるといった要素はありません。
  • 例えば、「パーティクルが千切れて消えていくマスターマテリアル」が欲しい‥となった場合には、千切れ用に32種類をさらに追加するのかどうかを検討します。

    千切れマスターマテリアルの場合は、基本的にアルファ合成しか用意しませんでした。
    また、SubUVに対応したものも用意していません。
    そうして8種類に絞ってリリースして様子を見て、「加算版が欲しい」という声が多く上がった際にはさらに追加を検討する‥という感じで対応していきました。
  • スプライトパーティクル用とメッシュパーティクル用に大きく2分してマスターマテリアルを用意しましたが、スプライト用のマテリアルをメッシュに使いたい場面があったり、その逆もあったりします。
    メッシュパーティクルでパラパラアニメさせたいとか、スプライトだけどフレネルを使いたいとか、そういう場合です。

    例えばスプライトパーティクル用のマテリアルだから片面でいいと思い片面に設定してしまうと、メッシュパーティクルに転用できなくなってしまいます。
  • この4つを心掛けています。
    どれもありきたりとは思いますが、少しだけ補足したいと思います。
  • 一般的にもよく言われていますが、マテリアルの管理者を1人に絞った方が良いというのは、経験してみてやはりその方が良いと思います。
    マテリアル作成をプログラマやTAの方が一手に引き受けている場合でも、エフェクトだけは特殊なのでエフェクトの人が担当する‥といったケースをよく聞きます。

    ただ、管理者がエフェクトの実制作作業を抱えると、スタッフからの要望対応やメンテナンスがおざなりになってしまいますし、しかしある程度、実制作をしないと必要性を判断できないので、区切りの良いタイミングで、メンテナンスに集中する期間をもらっています。
  • Static Switch Parameterを当初は使っていましたが、マテリアルインスタンス側で分岐を変えると別シェーダーになるため、大半のマテリアルインスタンスがマスターマテリアルと同等のファイルサイズになってしまうという事態が起きました。

    そこで開発途中からStatic Switch Parameterを完全撤廃しました。
    スイッチの切り替えは「管理者しか触らない」ルールにして、引き続き使用していくことも考えましたが、誰でも触れる状態になるので、うっかり触ってしまうヒューマンエラーを懸念して、断念しました。

    ただ、Static Switch Parameterは、スタッフ全員が理解する前提で使っていくのも良いと思います。
    その方がマスターマテリアルの数が減るので、メンテナンスは断然楽になります。
    その際には、マテリアルインスタンスのパラメータグループで一番下に並ぶようにグループ名を決めて、「一番下の項目は触らないでね」という形にするとヒューマンエラーは起こりにくいかも知れません。
    もしくは、スライドの右下の図のように「Dont Touch Me」のようなグループ名を付けて、触ったらダメだと一目で分かるようにするのも良さそうです。
  • ブレンドモードの変更に関しては、基本的にマスターマテリアルはアルファ合成で用意して、加算合成についてはマテリアルインスタンスのマテリアルプロパティオーバーライドで変更しました。
    つまり、加算合成だけ中間の親が存在して、スタッフは孫インスタンスを使うことになります。
    少しだけメンテナンスが楽になりました。

    マテリアルプロパティオーバーライドは、Static Switch Parameterと同じく別シェーダーになるので注意が必要ですが、設定する項目が区切られているので、アリとしました。
    「マテリアルプロパティオーバーライドは触らない」ようアナウンスして運用しています。
  • プロジェクト初期にコアメンバーで話し合って、かなりガチガチに決めていますが、いつも非常に悩ましく思っています。 今の形がベストとは思いませんが、何かしら参考になればと思って取り上げました。

    今回、命名規則で実施してとても良かったのが、アセットの制作者を識別する1文字をアセット名の先頭に入れたことです。
    このおかげで制作者が一目で分かり、非常に重宝しました(以前のプロジェクトからやってはいましたが、今回管理が非常に大変になって大きく恩恵があった)。

    例えばアセットを削除しようとしたら別のアセットが参照していて、誰に確認すればいいのか知りたい場合とか、不具合を見つけたアセットが誰担当なのかとか、エラーログにリストアップされたアセットが誰担当なのかを知りたい場合に、1つ1つサブミットの履歴を確認せずとも一目ですぐに分かります。
    また、クック後のファイル一覧からファイルサイズが大きいアセットをピックアップした際にも担当者が一目で分かります。
  • こちらはマテリアルの命名規則です。
    フレネルは f 、ソフトパーティクルは s といったように、マテリアルの機能が分かるような1文字を加えるルールにしていますが、パっと見ではどうしても分かりにくいです。
    悩ましいです。

    実施していて地味に便利なのが、SubUV用のテクスチャを使用している際に、8x4など縦横のパターン数をアセット名に含めておいた点で、そうするとテクスチャを目でみて確認せずともパターン数が分かるので、分割数を指定する際に楽でした。
  • パーティクルシステムだけは、アセット名の先頭は制作者ではなくVFXの「V」を入れています。
    これは他セクションと直接絡むアセットだからです。

    (ただ、その隣のカテゴリを1文字にするのは正直厳しく、被りまくります。例えば「エム」はマジック、マップ、ミッション、ミニゲームなど色々被って困りました。なので2文字は使った方が良いなと‥)

    命名規則をここまでがちがちに決めると、慣れるまでが面倒ですが、守ってもらうようにしています。
    ただしDevelopersフォルダ内のアセットの命名は自由です。
  • ちなみに、マテリアル関数についてはUE4標準で説明文を記入できる項目があります。
  • それから、パーティクルシステムにもタグ付けの機能を追加してもらいました。

    説明文を記述することができ、担当者、カテゴリ、属性、進捗状況などをプルダウンから選んで設定できます。
    そして、コンテンツブラウザ上でもポップアップ表示されます。
    こちらは、サウンドの方や敵担当プログラマや、または制作者じゃない人が、何のエフェクトか確認するのにとても便利です。
    それどころか、自分でも何のエフェクトだったか分からなくなってしまうので、説明文を入力する場所は必須だと思っています。
  • そして、パーティクルシステムを検索する、「アセットサーチャー」という独自のウインドウが作成されました。
  • 先ほど説明した、アセットに設定したタグの内容で検索をかけたり、エミッターが使用しているモジュールで検索をかけることが可能です。
    使用を廃止したモジュールや、ポストエフェクトに影響を与えるような、設定に注意が必要なモジュールを使用しているエフェクトをリストアップすることができます。

    また、エフェクトのプレビューが可能で、プレビューでのポストプロセスの設定変更も可能です。

    そして、カスケードを開かずとも、タグや重要な設定項目の変更を直接行うことが可能です。
  • そこで、セッションフロントエンドのオートメーションを使って、何からも全く参照されていないアセットのリストアップが可能な検索機能と、もしくはアセット名の末尾に参照数を付与してリストアップする検索機能をプログラマに追加してもらいました。

    ただし、何かに参照されていても製品には乗らないものもあるので、参照数に関しては、まずは大体の目安にするようにしています。
  • 似たアセットがありこちで生まれてしまうことがあります。
    これは汎用素材で賄えていないことの証なので、基本的には汎用素材を充実化させることで解決したいところですが、すでに似たアセットがいくつもあって、統合していきたい場合もあります。 そういう時には‥
  • 統合作業用にローカルコレクションを作って、そこに似たテクスチャを登録すれば、一覧できるので統合の検討や統合作業が楽になります。

    テクスチャだけでなく、メンテナンスしたいマテリアルを登録して、完了したら登録を外していくなど、コレクションには結構使い道があると思います。
  • ‥知っていると便利です。

    それから、削除してしまいたいアセットが何かで参照されている場合に、そのまま強制削除すると参照先でリンクが切れた状態になってしまうので、「削除しました」と文字で書いたテクスチャとそのテクスチャを使ったマテリアルを用意して、削除したいアセットの代わりにそれらを置換することで、参照先で「削除されたのだな」と一目で分かって便利です。
  • そんな時、テクスチャの設定に関しては、プロパティマトリクスを利用することで設定漏れを発見して、一括変更したりしています。
  • マテリアルに関してはプロパティマトリクスが使えないので、大量のマテリアルに対して修正しないといけない場合に、プログラマにコマンドレットを作成してもらったことが何度かあります。
    実行ファイルで直接アセットデータを書き換える形です。

    例えば、プロジェクト初期にモノクロテクスチャに非圧縮グレースケールを使っていましたが、BC4に置き換えるために用意してもらったことがあります。
    また、メインマテリアルノードの設定を一括変更するのにも用意してもらったことがあります。
  • ただ、開発が進むにつれて気軽に一括変更できなくなっていきました。
    それは、間違った設定のままエフェクトがFIXされていて、設定を変えると見え方が崩れるものが出たからです。

    なので、今後は設定の漏れがあるものをリストアップだけして、手動で変更していく方向で検討しています。
  • 巨大なサイズのテクスチャは、サイズマップで調べています。

    テクスチャのLOD Biasの設定は反映されませんが、Maximum Texture Sizeの設定は反映されます。
  • 私含めアーティストはハードウェアやソフトウェア周りに非常に疎いですが、良く分からない単語を知らないまま使うのが気持ち悪かったりするので、すごくシンプルにでも説明した方が安心してもらえると思います。
  • まず、ナイトリークックについて。
    開発途中から、毎晩自動でクック、パッケージングされるようになりました。
    その際に出力されるログに、クックされたアセットのパスが載っているので、秀丸マクロやエクセルマクロを使ってエフェクトのアセットをカテゴリごとに分けて、ざっくりと集計できるようにしました。

    ちなみに背景班は、集計するPythonスクリプトを用意していました。
  • それから、ナイトリークックの自動集計結果がグラフで表示されるウェブページが、プロジェクトのサイト内に用意されました。
    各パートごとのファイルサイズが一目で分かり、日々の推移も確認できます。

    こちらでデータの総容量を確認していました。
  • 手元でクックしてファイルサイズを調べたい時は、専用マップを作って、Unreal Frontendでクックしていました。
    ファイルサイズを調べるだけならデプロイして実機に出す必要が無いのでお手軽です。
  • ここで、各アセットをクックして判明したちょっとしたことを取り上げたいと思います。
  • UE4.13でPS4向けにクックしたものです。

    まずはテクスチャ解像度と圧縮方式を変えての計測結果です。
  • まず、注意が必要なのが非圧縮のグレースケールです。
    非圧縮ですが1チャンネルなので、本来はDXT5と同じサイズです。
    なので、綺麗なモノクロ画像が使いたい場面で有効だと思いますが、テクスチャエディタでsRGBの設定をONにすることができ、ONにすると非圧縮4チャンネルのサイズになるので注意が必要です。

    また、ベクターディスプレイスメントマップはインポート時の画像にアルファチャンネルがあっても無くても非圧縮4チャンネルのサイズになります。
  • 次に、テクスチャの各種設定を変えてみての比較です。
    LOD Biasの値を変えてみたり、Maximum Texture SizeやNever Stream、NoMipmapなどの設定を変えたものを比較しました。
  • LOD Biasにプラスの値を入れるとクック後のファイルサイズに反映されますが、マイナスの値を入れても反映されません。
    また、NoMipmapに設定すると、ミップマップを作成しないのでLOD Biasは当然、反映されませんが、Maximum Texture Sizeはちゃんと反映されます。
    なので、テクスチャの最大サイズを変えたい場合はLOD BiasではなくMaximum Texture Sizeで変えた方が良いと思います。
  • 次に、スタティックメッシュの分割数を変えてみての比較です。
  • それから、Mayaでの頂点カラーの設定の有無や、UE4にインポートした時のオプションにある「自動ライトマップUV作成」と「自動コリジョン作成」にチェックが入っていた時といない時で比較しました。
  • 結果、「自動ライトマップUV作成」と「自動コリジョン作成」にチェックが入っていると、約1.7倍のサイズになりました。

    どちらもエフェクトではほぼ使用しない上に、デフォルトではONになっているので、注意が必要です。
  • そしてマテリアルでも、ブレンドモードやシェーディングモデルなど、各種設定を変えてみて比較しました。
    計測したマテリアルの中身は、エフェクトでの標準的な構成です。
  • 一応計測した結果を載せてはいますが、UE4.14からマテリアルのファイルサイズが削減されるということですので、ひとまずは「ライティングを有効にするとサイズが増える」程度の認識で良いかと思います。
  • 次に、クックした時に、何が一緒にクックされるかについて。
  • まず、マテリアル内で未使用のまま残ったノード群は、クック後のファイルサイズに含まれてしまいます。
    特にテクスチャサンプラーノードが残っていると、参照しているテクスチャも一緒にクックされるので注意が必要です。
  • それから、パラメータ化したテクスチャノードに、デフォルトで設定しているテクスチャもクックされます。

    スタティックメッシュに直接、設定しているマテリアルもクックされます。
  • マテリアルエディタやマテリアルインスタンスのエディタのプレビューに、スタティックメッシュを使用していると、そのメッシュもクックされます。
    キャラや背景オブジェクトなどポリゴン数が多いものをプレビューに使っている場合にはご注意ください。

    また、マテリアル関数のInputやOutputノードに、プレビュー用に接続しているテクスチャも、クックされます。
  • カスケード上で非表示にしているエミッターが、参照しているメッシュ、マテリアル、そのマテリアルが参照しているテクスチャなど諸々のアセットも、クックされます。
    これは結構、注意が必要だと思います。
  • エフェクトアセットをゲーム中に表示して、見た目をチェックしたり処理負荷を計測したりするといったことについてお話します。
  • まず、UE4エディタ上でのエフェクトのチェックについて。
  • 実際の処理負荷は実機上で計測してみないと分かりませんが、シェーダー複雑度、パーティクル数、エミッター数、パーティクルに内包したライトの数や範囲は、パフォーマンス面での指標になります。

    特に、当プロジェクトではエミッター同士で親子関係が可能なよう独自拡張していますので、エミッターを100個生むような構成が簡単に可能で、エミッター数が多いとCPUのパフォーマンスが大きく落ちるので注意が必要でした。

    また、パーティクルのライトの数も、うっかり大量のパーティクルとともに生成してしまうと、画面がひきつるほどの負荷になります。
  • 次に、実機上でのチェックについて。
  • エフェクトチームに共有ブースがあり、そこでPS4上でプレイチェックしたり、処理負荷チェックしたりしました。
  • 具体的な処理負荷の計測の流れですが、まずは床と平行光源しかないマップを新規に用意します。
    そこに先ほどご紹介したエフェクト切り替え表示アクターを配置して、処理負荷を計測したいエフェクトを複数、登録します。

    次に、実機に出力したら、余計な処理を全てOFFにします。
    キャラクターをOFFにしたり、メニューをOFFにしたりです。

    また、処理が暴れるのを抑えるために、コンソールコマンドで垂直同期をOFFにし、フレームレートも天井を上げるためにMAX120フレームにしました。
  • 計測するエフェクトですが、この講演の冒頭のヒットエフェクトのような感じの構成のものを基準のエフェクトとして用意しました。
    エミッター5つのシンプルな内容です。

    そして、基準のものと比較したいエフェクトを沢山用意して、実機上で切り替えながら計測しました。
  • エフェクトを1個、中央にポツンと表示しても、誤差の範囲で計測しづらかったので、単体表示の場合と、25個敷き詰めて表示した場合と、それぞれを計測しました。

    ちなみに計測する値は、コンソールコマンド「Stat Unit」で表示される、Gameスレッド、Drawスレッド、GPUスレッドの各処理時間の値です。
    標準のエフェクトと比べて、こちらのエフェクトはGameスレッドが何ミリセック増えた、Drawスレッドが何ミリセック増えた‥といった感じで差分を出していきました。

    これをUE4のバージョンアップごとにはやってられませんが、一度やっておくと参考になります。
  • ちなみに、UE4.9の頃に計測した結果の中から、マテリアル関係のものをピックアップしました。
  • World Potision Offsetに関しては、頂点をテクスチャでもこもこさせる程度の構成です。

    Powerは1つのマテリアルに10個ほど入れてエミッター5つで計50個、さらにエフェクトを画面に25個、敷き詰めて表示して、GPUスレッドが微上昇した感じです。
    (Powerノードは色のコントラストの調整に使えてとても便利なのですが、重い重いと聞いていたのでなるべく使わないようにはしています。 
     ですが、マテリアル内に数個、単純な色の調整に使うくらいならそこまで過敏にならなくても良いのかなと思いました)

    DynamicParameterは、GPU負荷がかなり上昇した結果になりましたが、かなり怪しいです。計測ミスな気がします。こちらだけUE4.13で計測し直したところ、上昇は見られませんでした。

    半透明マテリアルのGPU負荷は、描画面積でも大きく変わるので、あくまで目安にしています。
  • UE4上でのチェックや、実機上でのチェックは以上のような感じになります。

    チェック関係で他にちょっとしたことと言えば、特に重たい表現は、使って大丈夫か?軽くならないか?など描画エンジニアに相談しています。
    例えばパララックス・オクルージョンは見た目も派手なのでバンバン使いたいけど重たいものの1つです。
    こちらは実機で計測して、step数に気を付けることと、使用する場面を限定してもらうよう班内に周知しました。
    例えば、画面上に大きく映る場合は、大技で画面に1個ならOK、といった感じです。
  • また、エフェクトの描画に不具合が起こった場合は、レンダードックでシーンをキャプチャーして、描画エンジニアに提出して調べてもらったりしています。
    シンプルなのでアーティストでも使いやすいと思います。

    キャプチャーデータを提出時には、描画のどのタイミングで不具合が起こっているか、分かる範囲で大まかに見て伝えるくらいはするようにしています。
    ライティングパスで起こっているのか、ブルームの時に起こっているのか、被写界深度の時に起こっているのか、といった感じです。
  • テクスチャ回りについての補足。
  • ケースバイケースであっても目安の提示は必要だと思います。
  • 最初はこちらのようなマテリアルを作成して調べました。
    ComputeMipノードを使用して数字のテクスチャを切り替えるマテリアルです。
  • その後、描画エンジニアがカスタムノードを使ったマテリアルを用意してくれました。こちらだと色付きで境目がとても良く分かります。
  • カラーテクスチャはsRGBの設定はONのまま運用しています。
    モノクロテクスチャはBC4なので、そもそもsRGBをONにすることはできずリニアなデータとして扱われますが、テクスチャ自体はPhotoshopでsRGB環境で作成するので、マテリアル内で2.2乗して暗くする必要があります。

    問題なのは不透明度の方で、不透明度も2.2乗しないと結果に対して違和感が出てしまいます。
    リニアな中間グレーを人間には「明るい」と感じるように、リニアな0.5の不透明度は「不透明に近い」ように見えてしまいます。
    そのため、不透明度にも累乗して対処しました。
    (テクスチャのアルファチャンネルをOpacityに接続する場合でも同様の注意が必要です)
  • 最初はPowerノードを使って2.2乗させていましたが、大半のマスターマテリアルに含まれることになるため、描画負荷を少しでも軽減させるためにPowerノードを減らすために代わりに乗算ノードで2乗させるようにしました。

    2.2乗と比べると若干明るい結果になりますが、許容範囲としました。
  • 頂点カラーもリニアな値なので2乗しています。
    特に頂点カラーのアルファの値は累乗して補正しないとモデルがなだらかに透明になっていくように見えません。
  • それから、「2乗しました」ということが一目で分かるようマテリアル関数化しました。
    中で2乗しているだけなのでほとんど意味がない関数ですが、分かりやすいとスタッフにも案外好評です。
  • ちなみに、もしも2.2乗する構成から2乗する構成に移行する場合、テクスチャをPhotoshopのレベル補正で中間ポイントを0.91あたりで調整すれば‥
  • 2.2乗の場合と2乗の場合で見た目がほぼ一致しました。
  • (こちらは検証してぴったり一致するのを確認しました)
  • エフェクトは突発的に表示され、しかも一瞬だけで、画面に近い場合も多いです。
    なので低解像度のMiplevelで表示されやすく、絵柄が炎のようにディティールがはっきりしたものは低解像度であることが目立ったため、例外的にNeverStreamをONにしました。
  • 次に、マテリアルについての補足です。
  • 講演の前半の方で軽く触れたSeparate Translucencyの設定ですが、こちらがONとOFFのマテリアルを混在させると、OFFにした半透明が描画された後にONの半透明が合成されて描画順に影響が出てしまうので、基本的にはどちらか一方に統一した方が良いと思われます。
    そして、例外的にもう片方の設定のマテリアルを使いたい場合に、どういう場面で使うかと、どう管理するかを考える必要が出てきます。
  • 今回のプロジェクトではSeparate Translucencyは各セクションと話し合った結果、基本的にOFFでいこうとなりました。
    被写界深度はカットシーンで入っていたり、ゲーム中にもほんのり入っていたりしますが、エフェクトに被写界深度の影響を与える方針です。
    なので、プログラマにSeparate Translucencyの設定をデフォルトでOFFにするよう変更してもらいました。

    その後、カットシーンでのみSeparate Translucency ONを使いたい場面がちょこちょこ出てきたので、ONにしたアセットを管理する専用のフォルダを用意して、最初はOFFのものと同名で保存するようにしていたのですが、同名だとアセットを検索した時に2つ引っ掛かってしまい危険なので、命名規則にSeparateを有効にしたことが分かる文字列を追加しました。
  • Usageについては必要最小限の設定にしたいところです。 しかし汎用マテリアルは私しかアクセス権が無いため、Usageに新たにチェックが入る度に報告をもらってサブミットするというのは手間なので、エフェクトで主に使用される、「Particle Sprites」、「Beam Trails」、「Mesh Particles」の3点については、あらかじめチェックONにしています。
    切り詰めたいなら、最低限のチェックにするか、またはBeam Trailsだけは外しておくのが良さそうです。

    ちなみに「Static Lighting」はスタティックメッシュに貼り付ける場合にチェックが必要ですが、UE4.13でクックしたところ、半透明マテリアルで「Static Lighting」にチェックを入れても、ごく僅かしかファイルサイズが増えなかったので、こちらもONにしておいて良いかも知れません。
  • 大量のマテリアルに対して、同じノード構成を組み込む必要があった際に、メインマテリアルノードの詳細パネル内に専用の項目を追加してもらいました。
    チェックボックスをONにするだけなので、設定がとても楽です。
    例えば、シーンの露出補正によってエミッシブカラーの値が保たれるようにするチェックボックスがあります。
  • (知っておいて損はないというくらいの?感じで)
  • プロジェクト初期の頃はRGBまとめて接続していましたが、プラットフォームによっては赤く表示される現象が出たためです。
  • エフェクト用のマテリアルで工夫しがいがある部分としては、まずはDynamicParameterの4チャンネルの値の活用があります。
    マテリアルインスタンスが大量に増える原因になっているパラメータを、DynamicParameterで賄うのが良い活用方法だと思います。

    それから、もしも色の指定が固定値で良いのなら、ParticleColorノードの4チャンネルの値を、別の何かに自由に使えます。
    例えば、屈折マテリアルでは、屈折の強さの制御に使っていたりいます。

    DynamicParameterとParticleColorを合わせると、エフェクト側から8つの値を自由に変更可能になります。
  • それから、マテリアルでParticleRandomノードを使えば、GPUパーティクルに限定されるものの、パーティクルごとに0~1のランダムな値を与えることが可能です。

    GPUパーティクルではDynamicParameterが使えないため、UVスクロールの初期値ランダムやSubUVの開始パターンのランダムに利用するといったことが考えられます。
  • それから、Static Component Mask Parameterノードを利用すると、RGBAの4つのチャンネルの中からどれを使用するかをマテリアルインスタンスで自由に切り替えられます。
    こちらを利用すれば、BC7のテクスチャにモノクロ画像を4つ格納して、マテリアルインスタンスで使用する画像を自由に切り替えられるので、夢は膨らみます。

    ただし、Static Switch Parameterと同様に、設定を切り替えると別シェーダーになるので、エミッシブカラーとオパシティで16通りの組み合わせの中間親のマテリアルインスタンスを運用する必要があり、そのままでは非常に分かりにくいアセット運用になってしまいそうなので、何かしら管理が楽になる工夫や拡張が必要な気がします。
  • 最後に、マテリアルの利便性を向上させるために行っていることです。
  • 面倒ですが徹底すれば、マテリアル関数の機能と使用方法のドキュメントを別途用意して、スタッフがいちいちドキュメントを開いて使い方を確認しないといけないという状況が和らぎます。
  • 適切なデフォルト値を入力することで、マテリアル関数を使用した際に効能がすぐ分かるようになり、そこで何を値を変えなくても標準的な効果が発揮されることで若干の手間を省けます。
    また、Use Preview Value as DefaultをONにすることで、マテリアル関数に何も入力しない状態でエラーになってしまうのを防ぐことができます。
  • コンテンツブラウザ上でマスターマテリアルの中身が一目で分かるよう、アイコン画像のテクスチャをデフォルトに指定して、サムネイル化する工夫をしました。

    ただしクック後のデータに含まれるので16x16の小さな画像を最低限の数だけ用意しました。
    これだけでも閲覧性はかなり上がりました。
    もうちょっと解像度を上げて、ソフトパーティクルのS、フレネルのFなどを画像に加えたものを用意した方が、より良いと思っています。
  • マテリアルインスタンスで親マテリアルを差し替えた時に、パラメータ名が同じ場合は設定内容を引き継いでくれるので、パラメータ名はシンプルでストレートなものが良いと思います。
    その前提の上で‥
  • 多くのマスターマテリアルに含まれるような基本的な設定項目だけは、設定しやすい順に並んで欲しかったので、エミッシブカラー、オパシティ、ノーマルなどの一部のカテゴリだけは、グループ名の先頭に連番を加えました。
    少なくとも汎用マスターマテリアルでは統一しているので、レイアウトが統一され、スタッフにとっては設定がしやすくなって良かったように思います。
  • それから、UV周りの計算順について。
    UVは先にスクロール速度を与えてから、その後にタイリングさせる方が良いです。
    そうすると、タイリング数を変えてもスクロール速度が変わりません。

    これはちゃんとやっておけば良かったと後悔している例になります。
    後から変更するとそれまで作成したアセットに影響が出るので修正できませんでした。
    こういった些細なことが、作業効率に影響するので、注意が必要なひとつの例になります。
  • さいごにもう少しだけ。

×