【Unite Tokyo 2018】なんとっ！ユナイト！ミリシタをささえる『ＡＫＡＮＥ大作戦』とは？

なんとっ！ユナイト！
ミリシタをささえる
『ＡＫＡＮＥ大作戦』とは？
DAY2 2018/5/8
池田早人
株式会社バンダイナムコスタジオ/リードプログラマ
加藤政樹
株式会社バンダイナムコスタジオ/プログラマーーーーー

©窪岡俊之 ©BANDAI NAMCO Entertainment Inc. 配信元：株式会社バンダイナムコエンターテインメント

自己紹介
2
池田早人
Hayato Ikeda
株式会社バンダイナムコスタジオ / リードプログラマ
・1996年にナムコにハードエンジニアとして入社
・2003年からモバイルアプリ向けプログラマとして今に至る
・ミリシタでは、クライアントエンジニアのまとめ役として、進行管理や
プロジェクトのバージョン管理(Perforce)などを担当
のり子、ジュリア担当

ミリシタって、なんなん？
3
『アイドルマスターミリオンライブ！シアターデイズ』は
株式会社バンダイナムコエンターテイメントからAndroid/iOS用に配信されている
アイドルライブ＆プロデュースゲームで、略称は『ミリシタ』です。
765プロライブ劇場(シアター)を舞台に
765 ミリオンオールスターズのアイドルたちをプロデュース！
ステージでのライブやお仕事、劇場でのコミュニケーションを通じて、
アイドルと「もっとふれあえる」要素がもりだくさん！
http://millionlive.idolmaster.jp/theaterdays/

ライブシーンについて
リリース時
5人のアイドルが歌って踊る
配置換えや、衣装変更が任意に出来る
5人が個別のモーションで踊る曲もある(フォーメーション)
51人のキャラで歌い分けが出来る曲もある
途中でスペシャルアピール(別モーション)が入る
運営中
4人や3人や2人で歌って踊る
52人のキャラで歌い分けが出来る曲もある
変身する曲もある
最新
13人のアイドルが歌って踊る 4

モデルデータについて
1体につき１００００ポリゴンくらい(顔1500/髪3000/体5500)
衣装テクスチャは1024×1024を1枚
表情はブレンドシェイプ
5

ステージデータについて
1ステージにつき１5０００ポリゴンくらい(ステージ10000/演出系5000)
ステージテクスチャは1024×1024が2枚
客席のコンサートライトは1メッシュなので描画負荷は軽い
6

ポストエフェクトと解像度について
被写界深度(DoF)
Bloom
Blur
フレア(光を被せるエフェクト)
UnityのImage Effectsは高品質だがモバイルには重いので、軽量化したシェーダーを独自実装
中間バッファの使い回しでメモリを節約
余分なパスなしで描画と同時にデプステクスチャを作ってDoFを実現
解像度:1280×720
低解像度+MSAA
GPU性能の低い端末向けに低解像度モードを用意したが、ジャギーが目立つためMSAAを検討
若干負荷は上がるが描画面積の多いシーンでは解像度を落とす効果の方が高く、メリットあり
7

タイミングシート(ステージイベントツール)について
いわゆるタイムラインツールで、家庭用にあった仕様を元にUnityで新規作成
ライブシーンの演出を作るために使用
ゲームデザイナーやビジュアルアーティストの要望を受けて、改良し続けている
カメラ、キャラの位置、キャラの表情、ステージ演出、コンサートライトの動きなど
全て制御している
カメラ用とステージ演出用の2種類がある
8

歌い分け
家庭用アイマスにあった機能で、アイドル毎にボーカルを収録している
ユニットを組んだメンバーの位置で歌うパートが異なる曲がある
５２名のアイドルから5人を順番に選ぶ組み合わせは５２Ｐ５で約3.1億通り
1曲2分半として、全部の組み合わせを聴こうと思うと465億秒必要になる(538194日で1474年必要)
サウンドはCRIのADX2を使用している
ボーカル用に複数チャンネルを使用し、ミュートを使うことで歌い分けを実現した
歌い分けのデータも前述のステージイベントツールで管理している
9

開発スケジュール
~2016/4 エンジニア+テクニカルアーティストで3Dでライブ実現の試作
~2016/6 α1製作タイトル>劇場>ストーリー>ライブまでの流れを実装
~2016/11 α2製作一通り必要な機能を実装
~2017/1 最適化プロジェクト開始
~2017/4 β1製作 AssetBundle化はまだ/サーバー通信
~2017/5 β2製作全体のレビュー開始
2017/6/26 ギリギリでUnityのバージョンを上げて、ストア提出
2017/6/28 ストア配信(iOS/Android)
2017/6/29 サービス開始
10

モバイル開発あるある
「端末での確認は、快適に動くiPhoneの最新機種でしか、やってませんでしたー」
その結果…「iPhone5sやAndroidでは、ガクガクでゲームになりません！」
分かってたけど、ミリシタでもやっちゃいました…
なんとかして対応しないとリリース出来ないが、開発メンバーは機能実装で手一杯。
開発プロジェクトとは別に動ける、最適化プロジェクトを立ち上げないと…
11

『ＡＫＡＮＥ大作戦』始動
簡単に言うと、Androidで快適にライブが遊べるための最適化プロジェクトの事です！
開発終盤からスタートしたため、開発チームとは別ラインで動ける
スペシャルチームを結成しました。
コードネームを付けた方が盛り上がりそうなので、ひとまず『AKANE大作戦』と命名。
Android Kousoku-ka And NativＥ-ka 大作戦
12
• 2D描画ベンチ
• 2D描画軽量化メモ
• 社内チームの見解
• AKANE大作戦 / String.StartsWith は遅い？
• AKANE大作戦 / ここ最近（06/19）のライブ処理負荷
• AKANE大作戦 / キャラモーション容量削減検証
• AKANE大作戦 / シアター、コミュ中のデバッグボタン
• AKANE大作戦 / ベンチマーク用のデーター
• AKANE 大作戦 / モデル、骨関連の調査
• AKANE大作戦 / ライブ UI のこれから
• AKANE大作戦 / ライブ中 UI の高速化
• AKANE 大作戦 / ライブ中のデバッグボタン
• AKANE大作戦 / ロード時間対策
• AKANE大作戦 / 検証項目一覧
• AKANE大作戦 / 独自実装アニメーションシステム
• AKANE 大作戦 / 背景エフェクト一覧
• AKANE大作戦の議事録
• AKANE大作戦の週報
• Android その他機種まとめ
• Android 各機種傾向
• レビュー版まとめ
• キャラ小物負荷目安
• スクリーンショット
• 他職種にお願いしたいこと
• 劇場・ADV 解析ページ
• 各ゲームパート処理負荷まとめ
• 描画モード別セッティングに関して
• 測定結果(Xperia Z4)
• 読込時間計測について
• 負荷対策情報交換会に向けて
• 重い子５

『ＡＫＡＮＥ大作戦』のアプローチ
プロジェクト設定の見直し
3D描画部分の高速化
CPUとGPUを効率良く見て行く
2D描画部分の高速化
CanvasからSpriteへ、透明部分の無駄な描画はないか、イメージのアトラス化など
スパイクさせない工夫
GCをしない、させない、やらせない
13

『ＡＫＡＮＥ大作戦』の目標
SetPassCall(DrawCall)の削減
GPU負荷の軽減
テクスチャーのアトラス化
Indexバッファの統合
マテリアルの削減
描画順序の調整
CPU負荷の軽減
揺れものの計算処理の高速化
処理のスレッド化(仕事をしてないCPUに働いてもらう)
メモリの最適化
GCを発生させないための工夫はないか？
結果として、平均FPSが60に近づくようにする。
(=16.6666…ms内に処理を終らせる)
14

『ＡＫＡＮＥ大作戦』のポリシー
ビジュアルのクオリティは下げない
多くの端末に対応させる(描画設定)
ギリギリまでエンジニアで頑張る
ポストエフェクトなしで…
揺れ物どうしよう…
LoDの検討…
フレームスキップは…
レンダリング解像度を下げる…
Boneのインフルエンス数を減らす…
15

プロファイル
大まかなCPU処理の傾向はUnityProfilerで見れる
GPUを見る場合は、Qualcommが配布しているSnapdragon Profilerを使う
計測環境を整えて、数値化して比較する
闇雲に最適化案を実装しても効果が計測出来ないので、変更を入れた場合は面倒でも
必ずProfileして、数値化して比較する
大きな変更も大した効果が無かったり、逆に些細なことが大きく影響したりするので
必ず計測環境を整えて監視することが重要
端末のクセを知る事も重要
機種により性能も動作の癖も千差万別なので、通常はこうしたらこうなるだろうという思い込みが
外れることは日常茶飯事
また、発熱によるクロックダウンの傾向は知っておいた方が良い
16

改修のアイデア
『ＡＫＡＮＥ大作戦』では様々な最適化のアイデアを出してもらい、リスト化し
優先順位を付けて、実装とテストを繰り返しました
数μSECでも縮められるなら、トライしてみる価値はある
ときには明らかに勝算が無さそうな事でも、あえて試してみることも大事
別の事で役に立つこともある！
頭の中だけで判断せず、たくさん手を動かすことが重要
17

実装とテスト
P 最適化アイデアの優先順位付け
D 実装
C ビルド&計測(Profile)
A 更なるアイデア出し
※ Plan(計画)→ Do(実行)→ Check(評価)→ Act(改善)
テストしやすいように、最適化項目をON/OFF出来るようにしておく
ビジュアルアーティストにチェックしてもらう時にも楽になる
負荷の重いキャラ(重い子5)で、計測する
18

Unityに関して
ゲームエンジンを使っている以上、出来る事と出来ない事がある
マルチスレッド化は、早めに手を引いた
短期間で実装出来ない事はやらない
そのうちUnityが対応してくれる機能もある
Uniteの講演動画や、Unity道場の資料はとても役に立ちます
Unity ForumやUnity Issue Trackerも活用してます
リリース後にUnityのバージョンを上げるのは大変なので、慎重に！
開発中は出来るだけ最新版を使うようにしてました
19

日々改善
リリース後も最適化作業は継続中！
ポストエフェクトの改修
マテリアルの統合
ステージ演出の軽量化
アニメーションシステムの独自実装による、処理負荷とデータサイズの削減
GCの削減
新機能の実装も行われているので、定期的にProfileを実行しています。
20

13人ライブ
それは昨年末、企画・開発プロデューサーの「ライブで5人以上出せない？」で始まった…
実は負荷テスト用に5人以上のキャラを表示する仕組みは、過去に用意していたので
ライブで15体表示する検証用プロジェクトをサクっと作成したところ
「あれ？けっこうちゃんと動く！」
と言う経緯で、3ヶ月弱でが完成しました。
13人ライブ用に、メモリ削減や負荷軽減のための特別な実装は行っていません。
バランス良く全体の負荷を下げる事で実現しています。
今までの最適化の積み重ねです。
塵も積もれば13人踊る！
21

前半まとめ
最適化の工数は事前に見積もっておきましょう
Profileは重要です
効果の見える化をしよう
最適化のPDCAを回そう
どんな些細な事でも、「ちりつも」で大きな結果となる
あと、コードネームを付けると楽しく最適化出来る… かもね！
22

プロフィール
23
(*) ビジュアル系プログラマー … モーション、グラフィクス系プログラマーのこと。
けっしてかっこいいわけではありません。

ミッション
24
見た目を変えずに
『アセットの作り直し』はしない
キャラのドローコールを減らそ
う

REPORT
25
２５→１7１体あたりのドローコール
サブメッシュ統合
モデル描画の細い制御が可能に
Command Buffer

キャラのモデルはこうなっております
26
パス２パス１
反転ポリゴンによる描画
頂点シェーダーで膨らませる
メッシュは具と共通
りんかく線
パス１：本体
パス２：りんかく線
シェーダー
服
スパン
コール
肌
キャラ
カラー

立ちはだかるサブメッシュの壁
27
ドローコールを
まとめたい
でも……
サブメッシュの壁は越えられない

Model と Mesh と SubMesh のわかれめ
28
Model
体
Sub Mesh
頂点構造の違いマテリアルの違
い
Mesh
頭（省略）

29
ところで

一般的な描画の話
30
頂点バッファー
インデックスバッファー
頂点の位置、ＵＶなど
頂点を結ぶ順番
描画に必要なもの
1 ( 1.0, 1.0, 0.0)
2 ( -1.0, 1.0, 0.0)
3
4
( 1.0, -1.0, 0.0)
( -1.0, -1.0, 0.0)
三角形 1 1-3-2
三角形 2 3-4-2
1
2
3
4
マテリアル
（今回は省略）

Mesh クラス作る系メソッド
31
いるいらない
インデックス
トポロジー
位置
UV
法線
カラー
インフルーエンス
頂点に関するメソッドはサブメッシュの指定が不要
(*) ミリシタ調べ。Unity 5.6 の場合。
サブメッシュ指定
SetIndices() SetVertices()
SetUVs()
boneWeight
s
SetNormals(
)
SetColors()
SetTangents() タンジェント

『Mesh』や『SubMesh』って？
32
ひとつの頂点バッファーを
複数のサブメッシュで小分けに描画している？
仮説
Mesh
Sub Mesh
インデックス
バッファー
Sub Mesh
インデックス
バッファー
Sub Mesh
インデックス
バッファー
SubMesh = インデックスバッファー？

ネイティブ実装なら
33
インデックスの範囲指定で、部分 or 全体を描画
Mesh
インデックスバッファーをひとつだけつくる

Mesh
Sub Mesh
インデックス
バッファー
Sub Mesh
インデックスバッファーーーーーーー
SubMesh を追加すればいいんじゃない？
34
全 SubMesh をマージした SubMeshを追加

試してみよう
35
何も変わらない
ちゃんと出た！
できた！
サブメッシュだけを追加してみた
マテリアルの配列を拡張、りんかく線だけのマテリアルを追
加

マージ SubMesh の追加
SubMesh の追加はこんな感じです
36
var rend = go.GetComponent<SkinnedMeshRenderer>();
Mesh mesh = rend.sharedMesh;
var new_indices = new List<int>();
for(int i = 0;i < mesh.subMeshCount;i++) {
var indices = mesh.GetIndices(i);
for(int j = 0;j < indices.Length;j++) {
new_indices.Add(indices[j]);
}
}
mesh.subMeshCount++;
mesh.SetTriangles(new_indices.ToArray(), mesh.subMeshCount - 1);
インデックスをひとつのリストにコピー
全 SubMesh の……
SubMesh の数
を増やしておく
マージされた SubMesh を
セット

Material の追加
Material の追加はこんな感じです
37
Material[] materials = rend.materials;
Material[] new_materials = new Material[rend.materials.Length + 1];
for(int i = 0;i < materials.Length;i++) {
new_materials[i] = materials[i];
new_materials[i].shader = find_no_outline_shader(materials[i])
}
new_materials[new_materials.Length - 1] = outline_only_material;
rend.materials = new_materials;
ひとつ大きなサイズの配列を確保
りんかく線なしのシェーダーに置き
かえる
りんかく線のみのマテリアルをセット

たぶん、こう
Unity の中身を想像してみた
38
mesh.vertexBuffer.Bind();
for(int i = 0;i < mesh.subMeshes.Count;i++) {
mesh.materials[i].Bind();
mesh.subMeshes[i].DrawIndexed();
}
(*) 疑似コードです
サブメッシュごとに描
画
マテリアルをバインド
頂点バッファーをバインド
インデックス描画
（ドローコール）

もっと減らしなよ～
お仕事結果
39
クオリティーを下げない
５人いますから（今は最大１３人）
あまり減ってない？
２５→１7
『アセットの作り直し』もない
ローンチにも間に合ったよ！

最適化前
40
(*) UI 等も含みます

最適化後
41
44 → 36
8 Draw call の減少
(*) UI 等も含みます

次の目標
42
マテリアル LOD
New!
近距離
遠距離
1ドロー化

マテリアルLOD の要件
43
サブメッシュ単位のビジブル制御
High LOD
Low LOD
Show
Show
Show
リフレクションなしありなし
A B A + B

Command Buffer
44
サブメッシュ単位で描画できる
CommandBuffer.DrawRenderer()

SkinnedMeshRenderer の描画を off にするには？
45
Renderer.materials[ ] を空っぽにする
スキニングは生きている
ついでにフラスタムカリングも
enabled を false にする
スキニングまで止まっちゃう！

描画だけ Off
SkinnedMeshRenderer の描画を off にするには？
46
org_materials = rend.materials;
rend.materials = new Material[0];
描画のときのために保存しておく
大きさ０の Material 配列を
セット

Command Buffer
47
Command Buffer を作る
CommandBuffer command_buffer = new CommandBuffer();
command_buffer.name = "Nantoh“;
Camera.main.AddCommandBuffer(CameraEvent.BeforeForwardOpaque,
command_buffer);
名前をつけておくと便利ですカメラに関連付ける

Command Buffer
48
毎フレームの描画
command_buffer.Clear();
if(rend.isVisible) {
for(int i = 0;i < org_materials.Length;i++) {
command_buffer.DrawRenderer(rend, org_materials[i], i);
}
}
前のフレームの描画コマンドを削除
フラスタムカリングの結果を利用

Materials 空っぽ化前
49

Materials 空っぽ化後
50
↑
こ
の
あ
た
り
に
注
目

Command Buffer の良いところ
51
描画順のコントロールが容易
サブメッシュ単位でのビジブル制御
マテリアルの切り替えも簡単

Command Buffer おまけ
52
Scene View のカメラも忘れずに！
Camera[] cameras = UnityEditor.SceneView.GetAllSceneCameras();
foreach(var camera in cameras) {
if(camera.cameraType == CameraType.SceneView) {
camera.AddCommandBuffer(CameraEvent.BeforeForwardOpaque, command_buffer);
}
}
Scene View のカメラにも
Command Buffer を関連づける

応用例
53
サブメッシュ単位のビジブル
Wire on shade（デバッグ用）

サブメッシュ単位のビジブル
54

Wire on shade（デバッグ用）
55
Mesh
ワイヤーフレーム用 SubMesh
トポロジーは “Lines”

最適化の考え方～ AKANE 大作戦の場合～
56
Unity は『ブラックボックス』？
でも『謎のテクノロジー』ではない
Unity の仕様を眺めているだけではダメ
ネイティブ実装の知識を生かした高速化
一般的な描画手法をどうやって Unity 上で実現するか

よくある質問「どうして『AKANE 大作戦』なの？」
57
高速化を始めたのは 2017 年のお正月

58
今年の干支は酉（とり）

59
西 ← 酉 → 茜

60
西 ← 酉 → 茜
命名『AKANE 大作戦！』

【Unite Tokyo 2018】なんとっ！ユナイト！ミリシタをささえる『ＡＫＡＮＥ大作戦』とは？

More Related Content

【Unite Tokyo 2018】なんとっ！ユナイト！ミリシタをささえる『ＡＫＡＮＥ大作戦』とは？