マジシャンズデッドポストモーテム ~マテリアル編~ (株式会社byking:...

UE4Material Management

Deep Dive

マジシャンズデッド　ポストモーテム

Ⓒ2016 BYKING Inc. All rights reserved. 　Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.

二部構成

デザイナー編

プログラマー編


デザイナー編


株式会社バイキング

リードステージデザイナー

なり　あい　しん　じ

成相真治


協力リードキャラクターデザイナー　鈴木寿弥リードエフェクトデザイナー　　岩崎武徳

自己紹介

マジシャンズデッドでの役割

リードステージデザイナーとして　・レベルモデルの作成　・アートイメージの作成　・リソース仕様の作成　・マテリアル作成と管理　・モデルデータ作成　・スケジュール管理


デザイナー編の内容

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

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

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

・マテリアル構造

・ワークフローの変化

・マテリアルの命名規則

マジシャンズデッド開発における開発事例紹介


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


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


簡単に言えば、

アーケード用の格闘ゲームです。


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


マスターマテリアル制作者

基本的に各セクションで使用するマテリアルは

各セクションのリードデザイナーが作成する。

（必要な部分をプログラマーサポート）

デザイナースキル

UE 未経験。

従来の開発環境での開発経験のみ。

（用意された設定を調整するレベル）Ⓒ2016 BYKING Inc. All rights reserved. 　Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.

開発開始時の状態

参考

・ UE4 マニュアル

・書籍

「 Unreal Engine 4 マテリアルデザイン入門」

「見てわかる UnrealEngine4 ゲーム制作超入門」

・優良 Web サイト様

技術サポート

・ヒストリア様

・ Epic 　 Games 様Ⓒ2016 BYKING Inc. All rights reserved. 　Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.

スキル習得

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


マテリアルファンクション（ MF ）とは？


マテリアル関数

複数のマテリアルで使い回せる便利なもの

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


① 基本機能

▼PBR 仕様 ▼ フレネル ▼Emissive と点滅

▼Texture Animation ▼Detail Map ▼Texture Blend


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


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


それぞれをマテリアルファンクションにして管理

① 基本機能

+② 本作特有機能

+③ プログラマー側の追加機能


①②③ をマテリアルファンクション（ MF ）管理

① 基本機能

② 状態変化

③ プログラマー側の追加機能


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


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


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

　　マスターマテリアル内を機能毎にマテリアルファンクションで分割した結果

▼ デメリット　・ノード構造の階層が深くなる　　（確認の際に複数の MF を開く必要がある）


▼ メリット　・各セクションで同時に調整が可能　・複数のマテリアルが一度に修正

マテリアル構造


マスターマテリアルの多機能化


マスターマテリアル

Switch で設定できる多数の機能を持った構造

汎用のマスターマテリアルから16 個の用途の異なる

MI を生成しています。

※Switch ＝ Static Switch Parameter の意味です。

マテリアルは 3 階層で管理

Ⓒ2016 BYKING Inc. All rights reserved. 　Ⓒ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


親


子

インスタンスの　　インスタンス

孫Ⓒ2016 BYKING Inc. All rights reserved. 　Ⓒ2015-2016 EXIGE GAMES Sdn.Bhd. All rights reserved.

マテリアル構造まとめ　

マテリアルの親・子・孫の三層構造による管理と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

ONNormal map OFF

MultiMap 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 の増加に対応できる構造　

プログラマーや他セクションが検索しやすく、　

　親子関係と用途が伝わりやすいシンプルな名前が理想

マテリアルの命名規則の理想


プログラマー編


株式会社バイキング

CTO　

すずき　たかし

鈴木孝司



自己紹介

マジシャンズデッドでの担当部位ネットワークの調査と基礎実装アウトゲームのフローとアセットローディング関連シェーダー (usf) に対する機能追加 AI 各種デバッグと最適化、さまざまな技術的問題解決

BP の利用は計画的に・・・

マジシャンズデッド制作時のパッケージサイズ肥大化問題について


シェーダーはどこに保存されているの？

エディターパッケージ

Derived Data Cache(DDC)

Materialまたは

Material 　Instance

パッケージとエディターで保存位置が変わる


とある日のマジシャンズデッドパッケージ

パッケージサイズ内訳

非マテリアルインスタンスマテリアルインスタンス

パッケージの総サイズ 30GB に対して60% がマテリアルインスタンス

うわっマテリアルインスタンス大きすぎ？


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 を多用していた

デザイナーに相談なんとか対応してもらえることに

ただし結構な作業量なので全部処理しきれるかわからない…


1つのマテリアルインスタンスが 10MB問題

総MI サイズ =各シェーダーサイズ × シェーダー数

UE4.13 の Shader Permutation Reduction が効く

かも篠山様談

マジシャンズデッドは、

4.12.5 で固定なので直接は使えないが

何かヒントがあるかも


Shader permutation reduction on 4.13-18% ただし Stationary Skylight

をプロジェクトで利用している・・・

利用できそうなものは無かった・・・


他になにかないか、プロジェクト設定を見ていたら・・・

これ、いらなくない？


マジシャンズデッドは DirectX11で動作

シェーダー数半減！

元のファイルサイズ SM4 のチェックを外した後

10.3MB 5.56MB

ターゲットが固定されているならSM4 を外すことでシェーダービルド待ち時間も減ると思うので

チェックを外しておくのがお勧めです


同じマテリアルをコンパイルしているのに特定の MI のサイズに変化が

シェーダー命令数が尋常ではないほど違う

1000 instructions → 450 instructions

マテリアルでなにかが起こっている・・・


4.13 でパッケージすると MI のサイズが激減しているような・・・

Instruction を増やしていた原因

原因は Noise ノード

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


マテリアルを最適化

Perlin ノイズは重いのでFastGradient+α に置き換え

1000 → 300Instructions最適化前最適化後

5.56MB 2.38MB

インストラクション数は直接サイズに影響する


最終ビルド結果

最初最終

総ファイルサイズ 30,000MB 14,700MBMI ファイル数 3,328files 4,200filesMI総ファイルサイズ 18,600MB 2,330MBキャラ向け MI 数 2,131

( 内 1,830 ファイルが 1MB以上 )

2,929( 内 878 ファイルが 1MB以上 )

キャラ用 MI総ファイルサイズ

17,500MB 2,010MB

背景用 MI 数 474( 内 277 ファイルが 1MB以上 )

529( 内 77 ファイルが 1MB以上 )

とあるキャラの MI サイズ 10.3MB 2.3MB


グラフ


ファイルサイ

ズ

マテリアル総

ファイルサイ

ズ

キャラ総ファ

イルサイズ

とあるキャラ

の MIサイズ (M

B)0.0GB5.0GB

10.0GB15.0GB20.0GB25.0GB30.0GB35.0GB

パッケージサイズの変化

問題発覚時最終ビルド

51％減 87％減 88％減 77％減

ビルド結果補足

デカイ MI が結構残っているけど・・・

両面描画フラグでもMI が肥える事が発覚

MI が増えてるけど・・・

調査開始と最終ビルドの間に

アセットが増えました

現在は修正済みです


まとめ


パッケージを作ってみないとわからないことがある Pak 化してると見逃しやすい

Jenkins でクック済みファイルサイズのログをグラフ化するなど

マテリアル → 子MI(static switch 有 ) → 孫MI の構造がオススメ必要なパターンの子MI を作っておくマテリアルインスタンスのファイルサイズ増加は読み込み時間やメインメモリ使用量に悪影響がある

( テクニカル ) アーティスト主導でマテリアルを作れるようになったがInstruction 数の肥大や重い命令などに注意が必要

1 ノードが 1GPU 命令に変換されるわけではないワークフロー中に命令数などのチェックを入れる

常に気をつける癖をつける！

アーティストおよびデザイナー向けのパフォーマンスガイドラインしかしながらすべてを監視するのは無理

解決法を模索していきましょう

https://docs.unrealengine.com/latest/JPN/Engine/Performance/Guidelines/index.html

ご清聴ありがとうございました


マジシャンズデッド ポストモーテム ~マテリアル編~ (株式会社byking:...

Engineering

マジシャンズデッドポストモーテム ~マテリアル編~ (株式会社byking:...