マジシャンズデッドポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD

UE4
Material Management
Deep Dive
マジシャンズデッドポストモーテム
Ⓒ2016 BYKING Inc. All rights reserved.
Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.

二部構成
デザイナー編
プログラマー編

デザイナー編

株式会社バイキング
リードステージデザイナー
なりあいしんじ
成相真治
協力
リードキャラクターデザイナー鈴木寿弥
リードエフェクトデザイナー岩崎武徳

自己紹介
マジシャンズデッドでの役割
リードステージデザイナーとして
・レベルモデルの作成
・アートイメージの作成
・リソース仕様の作成
・マテリアル作成と管理
・モデルデータ作成
・スケジュール管理

デザイナー編の内容
・マジシャンズデッドの紹介
・開発開始時の状態とスキル習得
・マテリアルファンクションの利用方法
・マテリアル構造
・ワークフローの変化
・マテリアルの命名規則
マジシャンズデッド開発における開発事例紹介

マジシャンズデッドの紹介

「マジシャンズデッド」って何？

簡単に言えば、
アーケード用の格闘ゲームです。

開発開始時の状態とスキル習得

マスターマテリアル制作者
基本的に各セクションで使用するマテリアルは
各セクションのリードデザイナーが作成する。
（必要な部分をプログラマーサポート）
デザイナースキル
UE未経験。
従来の開発環境での開発経験のみ。
（用意された設定を調整するレベル）
開発開始時の状態

参考
・UE4マニュアル
・書籍
「 Unreal Engine 4マテリアルデザイン入門」
「見てわかるUnrealEngine4ゲーム制作超入門」
・優良Webサイト様
技術サポート
・ヒストリア様
・ Epic Games様
スキル習得

マテリアルファンクションの利用方法

マテリアルファンクション（MF）とは？
マテリアル関数
複数のマテリアルで使い回せる便利なもの

どんなマテリアルが必要か？

①基本機能
▼PBR仕様 ▼フレネル ▼Emissiveと点滅
▼Texture
Animation ▼Detail Map ▼Texture Blend

②本作特有機能
▼背景物の状態変化

③プログラマー側の追加機能
▼背景物にカメラが入った際の透過機能

それぞれをマテリアルファンクションにして管理
①基本機能
+
②本作特有機能
+

①②③をマテリアルファンクション（MF）管理
①基本機能
②状態変化

マテリアルファンクション内は
結構ぐちゃぐちゃです…

実例紹介
機能毎にMF化したことで効率化した実例

マテリアルファンクションの
利用方法のまとめ
マスターマテリアル内を機能毎にマテリアルファンクションで分割した結果
▼デメリット
・ノード構造の階層が深くなる
（確認の際に複数のMFを開く必要がある）
▼メリット
・各セクションで同時に調整が可能
・複数のマテリアルが一度に修正

マテリアル構造

マスターマテリアルの多機能化
マスターマテリアル
Switchで設定できる
多数の機能を持った構造
汎用のマスターマテリアルから
16個の用途の異なる
MIを生成しています。
※Switch＝Static Switch Parameterの意味です。

マテリアルは3階層で管理
Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.※Switch＝Static Switch Parameterの意味です。

【1階層目】・・・親（共有フォルダ）
Switchを利用して多様性のあるマテリアル構造

マテリアルインスタンス
【2階層目】・・・子（共有フォルダ）
必要なSwitchをONにして使用方法を決める

【3階層目】・・・孫（各リソースフォルダ）
マテリアルインスタンスのインスタンス
Switchを変更せずに使用する

マテリアルは3階層で管理
【1階層目】・・・親（共有フォルダ）
Switchを利用して多様性のあるマテリアル構造
【2階層目】・・・子（共有フォルダ）
必要なSwitchをONにして使用方法を決める
【3階層目】・・・孫（各リソースフォルダ）
マテリアルインスタンスのインスタンス
Switchを変更せずに使用する
リードデザイナー
が作成と編集
各デザイナー
が作成と編集

マテリアル階層構造

孫マテリアルのファイルサイズ増大事件発生！

マテリアル数（リリース時）
キャラクター
9
52
2925
ステージ
25
68
502
エフェクト
20
600
0
親
子
インスタンスの
インスタンス
孫

マテリアル構造まとめ
マテリアルの親・子・孫の三層構造による管理と
Switchを利用し多機能化した少数のマテリアルで管理した結果
▼デメリット
・マテリアル内のノードが複雑化する
・シェーダーコンパイルに非常に時間が掛かる
▼メリット
・データサイズの最適化が可能
・修正や機能拡張の手間が1度で済む

マスターマテリアルを統合しないケース
・マテリアルのDetails内容（ Blend Modeなど）を変更する場合
・テクスチャアニメーションやテクスチャブレンドなど
特殊な機能を使用する場合
共有する機能が必要な場合は
マテリアルファンクションを利用

ワークフローの変化

プランナー確認
従来のワークフロー
修正
プランナー
デザイナープログラマー
パラメーター
ランタイム制御
※マテリアル処理に関わる修正
プログラム
対応待ち欲しいビジュアル
表現の説明

プランナー確認
UEのワークフロー
修正修正
マテリアル
ファンクション
デザイナー
プランナー
プログラマー
マテリアル
ファンクション
パラメーター
ランタイム制御
※マテリアル処理に関わる修正

ワークフローの変化のまとめ
▼デメリット
・管理するデザイナーの作業負荷が増大
（実作業スタッフに対しての説明は容易になった）
デザイナーがマテリアル構築に関わるワークフローになった結果
▼メリット
・修正対応の高速化（プログラム対応待ち時間が縮小）
・絵的な表現を直接制作できる

マテリアルの命名規則

命名規則について
名前で明記する必要のある内容
・マスター
マテリアル（親）
・インスタンス（子）
・インスタンスの
インスタンス（孫）
・キャラ班
・ステージ班
・エフェクト班
・汎用
・炎用
・水用
・モデル用
・デカール
・ポスト
・不透明
・1bitアルファ
・半透明
階層名セクション用途種類
（Material Domain）
アルファ
（ Blend Mode ）
・Change OFF
・Opacity ON
・Normal map OFF
・ Multi OFF
Switch名
・st100
・st101
・st102
ステージ名
・ext01
・mov02
・ground03
アセット名

マスターマテリアル（親）の命名規則
▼汎用マテリアルの場合
・M _ st _ base
▼炎魔法デカールの場合
・M _ st _ de _ tr _ Burnt
マスター
マテリアル
Stage
（セクション）
用途
Decal
（デカール）
Translucent
（半透明）
※マテリアル内のDetailsが汎用マテリアルと異なる場合に記述

マテリアルインスタンス（子）の命名規則1
▼汎用マテリアルのインスタンス場合
・ MI _ st _ base _
マテリアル
インスタンス
セクション
（ステージ）
用途
Switchによる用途の変化を全部入れると
名前が長くなりすぎる点とSwitch変更時に問題！
Ch _ Op _ No _ Mu_…
Change
OFF
Opacity
ON
Normal
map OFF
Multi
Map
OFF

古臭いけど最後の手段を使いました・・・
マジックナンバー‼
「この数字の意味はわからないが、とにかくプログラムは正しく動く。
まるで魔法の数字だ」という皮肉を含む数字。（ウィキペディアより）

親マテリアルとSwitchによる分岐を四桁の数字で管理
▼Switchによる分岐説明はエクセルで管理
MI_st_m0101…汎用マテリアルでシナジー変化あり
MI_st_m0102…汎用マテリアルでシナジー変化なし
MI_st_m0103…シナジー変化なしでエミッシブマスクを使用する
MI_st_m0104…シナジー変化なしでDetail Mapを使用する
・
・
・
▼汎用マテリアルのインスタンス場合
・MI _ st _ m0107
マテリアル
インスタンス
セクション
（ステージ）
親マテリアルを上二桁
の番号で表記
Switchによる分岐を
下二桁の番号で表記

サンプルスシーンを作成して説明

インスタンスのインスタンス（孫）の命名規則
▼モデル名（Static Mesh）
SM _ st100 _ ext05
▼テクスチャ名
T_ st100 _ ext05
MI _ st _ m0102 _ st100 _ ext05
ステージ名アセット名
▼最終的なモデルにアサインするマテリアル名
マテリアルインスタンス名
補足
「ext」はexterior（外観）の略。
建物外観などに使用。

マテリアルの命名規則まとめ
▼デメリット
・マテリアルインスタンス以降は用途が分かりにくい
作業するデザイナーへの用途説明としてサンプルシーンを作成
本作の命名規則を運用して感じた内容
▼メリット
・ファイル名がシンプルで短くなる
・検索しやすい
・SwitchによるMIの増加に対応できる構造

プログラマーや他セクションが検索しやすく、
親子関係と用途が伝わりやすいシンプルな名前が理想
マテリアルの命名規則の理想

エディターパッケージ
Derived Data
Cache(DDC)
Material
または
Material Instance
パッケージとエディターで
保存位置が変わる

パッケージサイズ内訳
非マテリアルインスタンス
パッケージの総サイズ30GBに対して
60%がマテリアルインスタンス
うわっ
マテリアルインスタンス大きすぎ？

運営時にアセットの追加や修正が
ある度にギガパッチを当てる
必要が出てしまう
アップデート時の
ダウンロード時間(＝更新差分サイズ)
には制限がある
このままではリリースできない

総ファイルサイズ 30GB
MIファイル数 3328files
MI総ファイルサイズ 18.6GB
キャラ向けMI数 2131(内1830ファイルが1MB以上)
キャラ用MI総ファイルサイズ 17.5GB
背景用MI数 474(内277ファイルが1MB以上)
とあるキャラの一つのMIサイズ 10.3MB

UDNに相談！
エディタで開いてみても
マテリアルやMIに異常はない
開発環境の
コンテンツフォルダ内では
ひとつ150K程度
パッケージすると
1つのマテリアルインスタンス
で10MBを超える

「マテリアルインスタンス内でスイッチな
どを使うとマテリアルインスタンスが肥大
化することがあります。」
S藤さんありがとうございました
末端MI(以後、孫MI)
でSwitchを多用していた
デザイナーに相談
なんとか対応してもらえることに
ただし結構な作業量なので
全部処理しきれるかわからない…

総MIサイズ =
各シェーダーサイズ×シェーダー数
UE4.13 の Shader Permutation
Reductionが効くかも
篠山様談
マジシャンズデッド
は、
4.12.5で固定なので
直接は使えないが
何かヒントがあるかも

-18% ただし Stationary Skylight を
プロジェクトで利用している・・・
利用できそうなものは無かった・・・

これ、いらなくない？
マジシャンズデッドは
DirectX11で動作

元のファイルサイズ SM4のチェックを外した後
10.3MB 5.56MB
ターゲットが固定されているなら
SM4を外すことでシェーダービルド待ち時間も減ると思うので
チェックを外しておくのがお勧めです

同じマテリアルをコンパイルしているのに
特定のMIのサイズに変化が
シェーダー命令数が
尋常ではないほど違う
1000 instructions → 450 instructions
マテリアルで
なにかが起こっている・・・

原因はNoiseノード
UE4.13でNoiseノードが
リファイン

Perlinノイズは重いので
FastGradient+αに置き換え
1000 → 300Instructions
最適化前最適化後
5.56MB 2.38MB
インストラクション数は
直接サイズに影響する

最初最終
総ファイルサイズ 30,000MB 14,700MB
MIファイル数 3,328files 4,200files
MI総ファイルサイズ 18,600MB 2,330MB
キャラ向けMI数 2,131
(内1,830ファイルが1MB以上)
2,929
(内878ファイルが1MB以上)
キャラ用MI総ファイルサイズ 17,500MB 2,010MB
背景用MI数 474
529
とあるキャラのMIサイズ 10.3MB 2.3MB

0.0GB
5.0GB
10.0GB
15.0GB
20.0GB
25.0GB
30.0GB
35.0GB
パッケージサイズの変化
問題発覚時最終ビルド

デカイMIが結構
残っているけど・・・
両面描画フラグでも
MIが肥える事が発覚
MIが
増えてるけど・・・
調査開始と
最終ビルドの間に
アセットが増えました
現在は修正済みです

マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD

More Related Content

What's hot

Viewers also liked

Similar to マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社Byking: 鈴木孝司様、成相真治様) #UE4DD

More from エピック・ゲームズ・ジャパン Epic Games Japan