Upload
unitytechnologiesjapan
View
9.701
Download
1
Embed Size (px)
Citation preview
Unityを使ったNintendo Switch™向けのタイトル開発・移植テクニック!!
ユニティ・テクノロジーズ・ジャパン合同会社
松岡貴之
講演資料の公開について
この講演のスライドは
CEDiLにアップロード済みです。
また、講演は録画されます。
講演資料の公開について
● 講演スライドの撮影 : 可● SNS への投稿 : 可
#cedec2017 / #cedecunity
まとめ
本日のまとめ
まとめ (1/3)
Nintendo Switch 開発者の方は
Unity を SDK インストーラから
すぐに無償で使用可能
まとめ (2/3)
Nintendo Switch開発者でなくとも
Unity 5.6.x で開発開始
まとめ (3/3)
開発のご質問は、開発者ポータル Nintendo Developer Portal 内
Unity 専用掲示板へ!
Nintendo Developer Portal: https://developer.nintendo.com/
完完
完完
ご清聴ありがとうございました!!
よく知らないんだけど
実際のところ
どんなことができるの?
実際にUnityを使っているタイトルは?
ロンチ時に5本
ロンチから半年で
40本リリース済み(2017年8月24日時点)
実際にUnityを使っているタイトルは?
40本って何本くらい?
実際にUnityを使っているタイトルは?
ニンテンドーeショップ内
販売タイトルの3割
40本って何本くらい?
実際にUnityを使っているタイトルは?
● Nintendo Switchロンチ時の発売タイトル
○ 任天堂「いっしょにチョキッと スニッパーズ」
○ コナミ「スーパーボンバーマンR」
○ スクウェア・エニックス「いけにえと雪のセツナ」
○ など、5本
実際にUnityを使っているタイトルは?
任天堂 / SFB Games
「いっしょにチョキッと スニッパーズ」
【Unite 2017 Tokyoでの Made with Unity ブース展示】
http://events.unity3d.jp/unite2017tokyo/booth.html
Nintendo Switch 用にデザインされた専用タイトル
実際にUnityを使っているタイトルは?
コナミ (開発 ヘキサドライブ)
【Unite 2017 Tokyo講演】
Unityを使ったNintendo Switch™ローンチタイトル制作
~スーパーボンバーマンRの事例~
https://www.youtube.com/watch?v=JwogVwg-zZ0
インターネットを含めた様々なマルチプレイ
(任天堂プラットフォームネットワーク機構のUnity版を使用)
実際にUnityを使っているタイトルは?
スクウェア・エニックス / Tokyo RPG Factory
【Unite 2017 Tokyo講演】
Nintendo Switch™ 本体同時発売必達、
家庭用向けRPG「いけにえと雪のセツナ」開発の裏側
https://www.youtube.com/watch?v=NZmwn2yq1HQ
他プラットフォーム(PC,PS)からSwitchへのポーティング
実際にUnityを使っているタイトルは?
● 市販の Nintendo Switch での知的財産の確認
ホームメニュー
> アプリ選択
> +ボタン押下
> ソフトの情報
> 知的財産の表記
実際にUnityを使っているタイトルは?
実際にUnityを使っているタイトルは?
意外と (?) いろいろできる
実際にUnityを使っているタイトルは?
独立系で
少人数の開発は
まだ無理?
実際にUnityを使っているタイトルは?
フライハイワークス / スキップモア / Kan.Kikuchi
「神巫女 -カミコ-」
【Made with Unity インタビュー】
2人×4ヶ月で作り上げた、懐かしさと新しさhttps://madewithunity.jp/interviews/kamiko/
2人のインディーゲーム開発者による短期間開発と
リリース (2017/4/13 - ロンチから6週後)Nintendo Switch 上半期DLランキングでも4位
実際にUnityを使っているタイトルは?
やる気と実力があれば
できる!
実力はある。やる気も
ちょっと あるけれど……
Unityは バージョンたくさん ありすぎて
どれが良いのか わからない
Unityエンジン開発の内情
● エンジン開発
○ Unity Editor や共通ランタイムは
デンマークや米国などが中心
○ Nintendo Switch版は日本で開発中
マルチ開発のためのロードマップ
● 2017年7月まで
○ Unity 5.5.0p1 ベースの Nintendo Switch 用ブランチ
○ 厳密には 5.5.0p1 の上位互換
○ マルチ開発の際に細かな違いがあった
マルチ開発のためのロードマップ
● 2017年8月から
○ Nintendo Switch 用 Unity 5.6.x○ Unity 5.6.x の本流にマージ済み
■ パッチ等のリリーススケジュールも同じ
現時点では2週間に1度
マルチ開発のためのロードマップ
● 2017年8月から (Nintendo Switch 用 Unity 5.6.x)○ 一般に配布されている Unity エディタに
開発者ポータルで配布されている
Nintendo Switch アドオンを追加して開発
○ Unityのプラットフォーム切り替え機能を用いて、
マルチ開発が可能
マルチ開発のためのロードマップ
Build Settings 内でPlatform の1つとして Nintendo Switch を選択可能
マルチ開発のためのロードマップ
● 2017年内には
○ Unity 2017.x へ合流
マルチ開発のためのロードマップ
● プラットフォーム特有の制約に注意
○ プラットフォームのSDKバージョンの整合性に注意
■ Nintendo Switchに限らず発生する
○ iOS の皆殺しバージョンのようなもの
■ 全員そろってマイグレーションする時期がある
リリース予定日、SDKおよびUnityのバージョンに注意
マルチ開発のためのロードマップ
● ネットワーク
○ 任天堂さまより、任天堂プラットフォーム固有の
ネットワークライブラリの Unity 版を提供中
(スーパーボンバーマンRでも使用)
○ UNetはロードマップ上に存在するが、
リリース時期未定
マルチ開発時の互換性
マルチ開発時の互換性
かなり高い
マルチ開発時の互換性
● 「いけにえと雪のセツナ」での例
○ Unity 5.2 で製作
■ PS4, PSVita, Windows でリリース
○ Nintendo Switch ロンチ時に
Unity 5.5 でポーティング版リリース
■ 参考資料 https://www.slideshare.net/Unite2017Tokyo/unite2017-tokyo-day2halld51310kumagai
マルチ開発時の互換性
● 豪華めのアセットも動作
● アセットストアで販売されている
「ArchVizPRO Interior Vol.3」もNintendo Switch上で60fps動作可能
https://www.assetstore.unity3d.com/en/#!/content/62337
マルチ開発時の互換性
● Nintendo Switchのアーキテクチャ
○ PC、据え置き、モバイルとの距離が近い
○ コンピュートシェーダなども動作
モバイル機とのマルチ開発時の指針
モバイル機とのマルチ開発時の指針
フツーに作って良い
モバイル機とのマルチ開発時の指針
● どれくらい動くのか?
○ 標準的なモバイル機向けのゲームは、問題なく
Nintendo Switch 上で動作する
ただし、UI、通信、ROM容量などは
注意が必要
はやめの実機チェックも忘れずに!
モバイル機とのマルチ開発時の指針
● どのように開発をはじめるか
○ デスクトップ機で開発開始
○ ゲームの形がわかるまでは、制約を気にしない
■ 開発初期には、何が重要なのか分からない
■ 形を作り、大事なものを見極めることを優先する
○ コード設計は後々のデバッグ、変更に耐えうるように
■ 例:ロード処理、非同期処理などは注意が必要
■ 最初は簡単にラップする程度で良い
モバイル機とのマルチ開発時の指針
● ゲームの形がわかってきたら、
下限ターゲット機とメモリ予算を決める
○ 例:iPhone5S世代を動作対象に入れるか?
○ 「Unity 数字で見るゲーム市場」などを参照
○ メモリ容量
■ モバイルでは厳しい(搭載メモリの25〜50%)■ Nintendo Switch ではより多くのメモリが使用可能
モバイル機とのマルチ開発時の指針
● 調整&量産
○ 複数のターゲット機で実行
○ テクスチャサイズ
○ レンダリング解像度
○ ポスト処理
■ 例:下限機でも、カラーグレーディングだけ有
○ フレームレート
■ マルチ開発では可変フレームレート前提で考える
モバイル機とのマルチ開発時の指針
● 調整&量産 (Nintendo Switchでは?)○ 複数のターゲット機で実行
○ テクスチャサイズ (メモリ予算が潤沢→余裕がある)○ レンダリング解像度 (ポスト処理負荷と相談)○ ポスト処理 (けっこういける)
■ 例:下限機でも、カラーグレーディングだけ有
○ フレームレート (QA&調整を考え、他機種に合わせる)■ マルチ開発では可変フレームレート前提で考える
Nintendo Switch の3モード (携帯・テーブル・TV)
Nintendo Switch の3モード (携帯・テーブル・TV)
3モードで遊べる
● 携帯モード・テーブルモード・TVモード
○ 共通点:常に 16:9, 60Hz, VSync有
Nintendo Switch の3モード (携帯・テーブル・TV)
3モードで遊べる
● 携帯モード・テーブルモード・TVモード
○ 共通点:常に 16:9, 60Hz, VSync有● 解像度が違う
○ 本体:1280x720, TV-HDMI出力:1920x1080● 性能が違う
● Joy-Conの操作方法が違う
● TVモード以外ではタッチパネル使用可
Nintendo Switch の特徴
3モードで遊べる
● 携帯モード・テーブルモード・TVモード
○ 共通点:常に 16:9, 60Hz, VSync有● 解像度が違う (場合がある)
○ 本体:1280x720, TV-HDMI出力:1920x1080● 性能が違う (場合がある)● Joy-Conの操作方法が違う (場合がある)● TVモード以外ではタッチパネル使用可 (使っても良い)
Nintendo Switch の特徴
3モード (携帯・テーブル・TV)● 絶対に3モード対応しないとダメなの?
→ 対応したほうが良い
● ユーザは対応を期待している○ 大きなゲーム、小さなゲームともメリットがある
■ 電車でひと駅だけ遊ぶ(携帯モード)■ 昼休みや出先で遊ぶ(テーブルモード)■ TVにつないでじっくり遊ぶ(TVモード)
ここまでのまとめ
● 既にタイトルが多数リリース済(40本)● Unity 5.6.x で開発
● マルチ開発可
● 特別な配慮をしなくても動作する
○ が、実機チェックも忘れずに!
● 3モード (携帯・テーブル・TV) 対応はしたほうが良い
Nintendo Switch が
スイッチするときに
何が起きるか?
スイッチ!
変更通知
● TV/非TVスイッチ時、および性能変更時はOSから通知が来る
● Nintendo Switch 用 UnityでもOSの通知を受け取れる
○ コールバック関数を登録して受け取る
○ Nintendo Switch 用 Unity 内にサンプルあり
● これを利用してUIや解像度等を変更することができる
○ 何もせず、デフォルトの挙動に任せても良い
スイッチ!
● TV モード(ドック状態) と非 TV モードで
本体動作に差がある
○ タッチパネル
○ 解像度
○ 性能
スイッチ!
タッチパネル
● TVモード時(ドック時)は使用不可
○ 触れない
● タッチパネル専用 or 併用のUIに注意
○ 例:バーチャルスティックで操作、メニューはタッチ
○ UGUIなどでタッチ、スティック両対応を考える
スイッチ!
出力解像度
● TVモード時は 1920 x 1080 ピクセル
● 非TVモード時は 1280 x 720 ピクセル
● UI表示が大きな影響を受ける
○ 基本的に 1920x1080 に合わせて素材を作る
○ 1280x720 時には縮小表示する
○ フォントは TextMeshPro など、
スケーリングがきれいなものも検討
スイッチ!
レンダリング解像度 (1/3)
● Nintendo Switch 用 Unity のデフォルトの挙動
○ 自動的にレンダリング解像度を変更する
○ TVモード時は 1920 x 1080 ピクセル
○ 非TVモード時は 1280 x 720 ピクセル
● 挙動は開発者側で変更可能
○ レンダリング解像度を変更しないことも可能
スイッチ!
レンダリング解像度 (2/3)
● お勧めの方法(特にマルチプラットフォーム開発時)
○ 3Dレンダリング用のRenderTextureを自分で用意
■ ターゲット機に合わせて解像度を変える
○ UIレンダリング前にアップスケールする
■ UI用カメラを用意し、そこでアップスケール
■ その後、UIを実寸でレンダリング
スイッチ!
レンダリング解像度 (3/3)
● キャプチャしている場合に注意
○ 例:ポーズ時などに、レンダリング結果を
キャプチャ&加工し、そのまま TV/非TV モードが
変更される
● 対応策
○ キャプチャしなおす
○ 解像度が変わっても何もしない
スイッチ!
性能
性能が変わるが、基本的に何も考えなくて良い
● CPUはいつも十分なパワーがある
○ 例:TV/非TVでロジックを変える、等は必要無し
● GPUは出力解像度に対し十分パワーがある
○ 例:出力とレンダリング解像度が比例していれば問題無
● 詳細はSDKのドキュメントを参照
スイッチ!
性能変更
● 性能変更時に一時的に大きな処理落ちが
発生する場合がある
スイッチ!
● 処理落ち時には…○ 処理落ちしているため、Time.deltaTime
(1フレームにかかった時間)がかなり大きくなる
○ バグの例 : 壁の方向に向かってスティックを
倒したまま、クレードル挿抜を行うと、壁抜け発生
スイッチ!
● 処理落ち
○ 実際にはどのプラットフォームでも発生しうる
■ Nintendo Switch固有の問題ではない
○ 対策して損はない
スイッチ!
● 処理落ちに対する、簡単な対策
○ TimeManager を開く
■ Edit > Project Settings > Time○ Maximum Allowed Timestep を小さくすることで
Time.deltaTimeの最大値を制御可能(デフォルトは0.33秒)
スイッチ!
● 処理落ちに対する、簡単な対策
この値を 0.033 などに設定
スイッチ!
● 処理落ち対策
○ 「ならFixedUpdate()にすると?」
■ 一定の実時間内に呼び出される回数を保証
■ が、おすすめしません
○ なぜ?
■ フレームレートが逆に不安定になる
■ フレームレート変更不能
■ 他のアセットの挙動の整合性がとりにくい
スイッチ!
● さまざまな情況のクレードル挿抜エミュレーション可能
○ SDK内にツールあり
■ 手で抜き挿ししなくても良い!
○ QA前に必ず確認
スイッチ!(まとめ)
● タッチパネル
○ 対応する場合、タッチ、Joy-Con両対応UIを考える
● 解像度
○ 面倒なら、デフォルトの挙動にまかせて良い
○ できれば、可変解像度に対応させる
● 性能
○ 基本的に、気にしなくて良い
○ が、挿抜時の処理落ちに注意
ここからは
いろいろ技術的なお話
こまごまとした
注意点を挙げます
Fixed Timestepの調整
Fixed Timestep の調整
● Fixed Timestep の調整
○ TimeManager を開く (Edit > Project Settings > Time)○ Fixed Timestep を 0.02 (1/50, デフォルト値) から
0.01666 (1/60)に変更
Fixed Timestep の調整
● Fixed Timestep の修正
○ デフォルト値 (0.02秒 = 50Hz) の場合、
実際の VSync周期 (60Hz)と合わない
○ よって1フレームにゼロ回や複数回
FixedUpdate()が実行される場合がある
○ 結果として、スパイク(処理の急激な増加)
が発生する
○ Unity 内蔵の Profilerで確認可能
Unityのプロジェクトを
開くのが面倒くさい
複数のバージョンのUnityを
使う必要があって困っている
複数バージョンのUnityの使用
● 複数バージョンの Unity のインストール
○ どのUnityも、任意のディレクトリにインストール可能
■ インストーラで指定
複数バージョンのUnityの使用
● バッチファイルから起動
set "UNITY=インストールしたディレクトリ\Editor\Unity.exe"set "PROJECT=プロジェクトのパス"
start "" "%UNITY%" -projectPath "%PROJECT%"
複数バージョンのUnityの使用
● プラットフォーム指定可能
set "UNITY=インストールしたディレクトリ\Editor\Unity.exe"set "PROJECT=プロジェクトのパス"set "TARGET=Switch"start "" "%UNITY%" -buildTarget %TARGET% -projectPath "%PROJECT%"
複数バージョンのUnityの使用
● Unityプロジェクトのパスとは
○ Assets ディレクトリを持つパス
C:\MyProjects\MyTest\Assets\
内にアセットがあるなら
set "PROJECT=C:\MyTest\MyTestProject"
古いバージョンの
Unityから持ってくるとき
古いバージョンのUnityからのポーティング
● 通常のUnityのバージョンアップと変わらない
○ ネームスペース、API名の変更(ほぼ自動)
○ 非互換な機能(すみません…)
○ 追加された機能
■ Texture Importer などインポータ設定は確認が必要
■ 追加されたプロパティは多くの場合自動的に
イネーブルになる
■ 「余計なお世話」となってしまうときがある
Joy-Conからの入力
Joy-Conからの入力
● Joy-Con○ 付属のネイティブプラグインの使用を推奨
■ HD振動、加速度・ジャイロセンサー
横持ち(「おすそわけ」)などにも対応
○ Joy-Conの仕様は意外と大きい
Joy-Conからの入力
● Joy-Con○ 現状は、付属のネイティブプラグインから
uGUIを操作できない
■ これを解消するには開発者側での
InputModule の実装が必要
○ 近い将来、InputModule を提供
Joy-Conからの入力
● InputMangerによるJoy-Conアクセス
○ 現状は1人用の持ち方にのみ非公式に対応
■ Joy-Conの「縦持ち」および、Proコントローラー
■ Windows上のXbox360コントローラと軸番号、
ボタン配置互換
■ PCで開発してそのまま実行可能
○ HD振動、加速度・ジャイロセンサー、横持ち未対応
○ 簡易的な「動作確認用」の機能と考える
セーブデータ
セーブデータ
● セーブデータ
○ 付属のネイティブプラグインの使用を推奨
○ Nintendo Switchに限らず、コンソール機向けUnityは、
PlayerPrefsに対応していない
■ アカウント等の扱いがからむため
○ 何らかの方法でシリアライズしてセーブ・ロード
パッチ
パッチサイズは
できるだけ小さく
Asset Bundleを必ず使う
パッチ
パッチ(まとめ)
● モバイル系プラットフォームで用いられている
基本的な技法を踏襲する
○ AssetBundleを小さめの粒度で作る
■ 例:プレイヤー1,2、敵1,2,3、設置物1,2,3○ Resourcesは最小限に
○ Streaming Assetsも検討
○ シーンに直接アセットを入れない
パッチ
● Unityを使う場合、基本的に変更のあった、
ビルド後のファイルがパッチ対象となる
○ 実行ファイル
○ Resources(フォルダ内全体で1ファイル生成)
○ シーン(シーンごとにファイル生成)
○ アセットバンドル(開発者が指定)
パッチ
● 実行ファイル
○ 対処方法なし
パッチ
● Streaming Assets○ 音楽、動画など
○ マルチプラットフォーム開発時は他の
プラットフォームのアセットが混じらないように注意
パッチ
● Resourcesフォルダ
○ ビルド時に1つのファイルになる(resources.assets)○ Resources内のファイルが変更された場合、
Resources全体がパッチ対象になる
○ このため、Resources内の容量は最小化するのが望まし
い
パッチ
● シーン
○ ビルド時にシーン毎にファイルを生成
■ シーン内の全アセットが単一ファイルになる (sharedassetsN.assets)
○ シーンに直接アセットを入れている場合、
シーン内の何か1つを変更すると、
ビルド後のシーンファイル全体がパッチ対象となる
○ 結果として、パッチが非常に大きくなる
パッチ
● Asset Bundle○ どうやって分けるか?
■ 「変更のありそうな単位」にする
■ 「プレイヤーA」「敵A」「敵B」などなど
○ ワークフロー上の負担も考慮
■ 「Unite Tokyo アセットバンドル」などで検索
○ Asset Bundle Graph Tool (午後の講演)
動画を流したい
動画
● MP4 + H.264に対応
● 再生フレームレートは 60.00 fps○ NTSC の 59.94Hz ではない
● Nintendo Switch用Unity内にサンプルコード付属
microSDカードへの対応
microSD カード
● 速度を気にしすぎる必要は無い
○ 遅い microSD カードなど
● 音楽や動画の再生がうまくいかない場合はあり得る
● その場合でも「落ちない」「進行不能にならない」ようにする
https://www.nintendo.co.jp/support/switch/data_management/microsdcard/
本体内蔵フォントを使う
本体内蔵フォントを使う
● Unity上で、本体内蔵フォントを使うことができる
○ 通常のフォントとして使用可能
○ 中国語(繁体字、簡体字)など、
容量が大きいものに使うと便利
○ ユーザ名表示等は企画上「当たり前の機能」という位置づ
けだが、マルチリージョン、言語対応を独自フォントで真面
目に実装すると大変
なぜかガクガクする
Unity Editor 内蔵
Profilerを使いましょう
プロファイリング (Unity Profiler)
● Unity Editor 上でも、実機でも使用可能
○ Development Build を指定する
● Unity Editor 上で確認
○ Window > Profiler
プロファイリング (Unity Profiler)
● 関数ごとの時間
● メモリアロケーション量
● CPUやメモリのグラフ
プロファイリング (Unity Profiler)
● スパイク(処理量の極端な増加)に注目する
● Unity Editor (≒ PC) 上でスパイクが出ていたら、
ほぼ必ず実機でもスパイクが出る
● まずは Editor 上でスパイクをすべて潰す
● PCビルド版も試す
● その後実機で計測を必ず行う
○ PCと実機は違う!
プロファイリング (Unity Profiler)
● スパイク(処理量の極端な増加)のよくある理由(1)○ Garbage Collection (GC)
■ GC Alloc を削減
■ 文字列操作、特にデバッグログ生成に注意
■ Mono Heapの大きさに注意
● Mono Heapが大きいほどGCに時間がかかる
プロファイリング (Unity Profiler)
● スパイク(処理量の極端な増加)のよくある理由(2)○ Physics関連
■ Fixed Timestep (前述) を見直す
○ ロード、インスタンス生成や非同期処理
■ 何をロード、処理しているか追いやすくする
プロファイリング (Unity Profiler)
● 実機でのプロファイリング (Unity Profiler)○ 「PC比で何倍の時間がかかっている」かを調べる
■ PC上での性能目標を定義しやすくなる
○ PCと比べてワーカスレッド数が違う点に注意する
■ Unityのエンジン内のマルチスレッド処理の
実行速度が変わる
● Physics, Renderer, Occlusion Culling など
ワーカスレッドの動作の確認方法
プロファイリング (Unity Profiler)
プロファイリング (Unity Profiler)
● Deep Profileを使う
プロファイリング (Unity Profiler)
● Deep Profileを使う
○ Editor, 実機とも使用可能
○ 処理速度は低下する
○ 代わりに関数単位の詳細な計測が可能
■ 時間
■ GC Alloc○ 性能目標を定めてから使うと良い
■ 例:「あと 2ms 削りたい」
プロファイリング (Unity Profiler)
【Unite 2017 Tokyo】最適化をする前に覚えておきたい技術
(弊社 黒河による)https://www.slideshare.net/UnityTechnologiesJapan/unite-2017-tokyo-75775983
https://www.youtube.com/watch?v=rvnsU8oCMcI
ロード時間やガベージコレクション対策あり
SDK付属の
CPUプロファイラを使う
SDK付属CPUプロファイラ
● いつ使うか?
○ 最初はUnity内蔵のプロファイラを使う
○ もう詰められる部分が無くなったときが出番
○ IL2CPPの出力結果を見るので、実際のC#のコード上での
クラス名、関数名が分かりにくい場合がある
ポストエフェクトを盛って
画面をボカしたり
キラキラ☆させたい
Post Processing Stackを使う
Post Processing Stack
● Unityの標準ポスト処理
● Image Effectsはレガシー扱い
○ Post Processing Stack のほうが1.5 倍ぐらい高速
● Asset Store 版と GitHub 版がある
https://github.com/Unity-Technologies/PostProcessing
○ GitHub版のほうが頻繁に更新されている
Post Processing Stack
● Post Processing Stack (詳しくはWebで!)
【Unite 2017 Tokyo】ゲームの見た目も盛ったら変わる!!!!ヤバい!!
ポストプロセス!!入門!!!!!!!!!
(弊社 高橋による)https://www.youtube.com/watch?v=r5mNmH68KPQ
Post Processing Stack の使い方の説明
GPUが重い?
ような?
気がする?
レンダリングとGPUデバッガ
● プラットフォームを問わず、GPUネックのケースは意外と多い
● 開発後半までひきずることもある
● 早期に問題を特定したほうが、後で楽になる
○ アセット量産前がベストなタイミング
● ポーティング時に、GPU特性の違いで重い場合もある
レンダリングとGPUデバッガ
● 何を調べるか?
○ GPU処理上の問題の有無
■ 本当にGPUが重いのか?
○ 最適化の対象候補
■ どの処理が重いのか?
○ 最適化案
■ どのように処理を軽減するか?
レンダリングとGPUデバッガ
● まず、本当にGPUが重いのか確認
レンダリングとGPUデバッガ
● まず、本当にGPUが重いのか確認
○ Development Buildで実機実行し、コンソールを確認
レンダリングとGPUデバッガ
○ カメラの Viewport Rect の Width, Height を0.25 などにして、擬似的に解像度を下げて実機で実行
● フレームレートが向上するならGPUネックの可能性有
レンダリングとGPUデバッガ
● GPUがボトルネックだと判明したら
● 無駄な描画をしていないか、PC上で調査
○ RenderDocをインストール○ https://docs.unity3d.com/Manual/RenderDocIntegration.html○ Unity Editor上で描画のキャプチャができる
レンダリングとGPUデバッガ
● RenderDocキャプチャ
● DrawCall単位の確認が可能
○ 描画先
○ 描いているポリゴン
○ シェーダ
○ 使用しているテクスチャ
○ テクスチャのフォーマット
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ 一見あり得ないミスに見えるが、高い技術と経験のある
チームでも、忙しくなると確認を忘れがち
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ 無意味なカメラが動いていないか?
■ → カメラをディゼーブルに
■ 動作しているカメラ数を表示して自衛
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ 無意味なポストエフェクトは無いか?
■ → ポストエフェクトを切る
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ 完全に透明な半透明ポリゴンを描画していないか?
■ → 完全に透明になった時点で描画をやめる
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ いつも隠れてしまうものを描画していないか?
■ → 隠れることが分かる場合、描画しない
■ 複雑なシーンにはオクルージョンカリングも検討
レンダリングとGPUデバッガ
● RenderDoc上で確認すべきことの例
○ 隠れる面積が大きい不透明ポリゴンを、奥→手前の順で
描画していないか?
■ → 可能なら、手前→奥になるように、 Material.renderQueue を調整
■ 例:「地面」や「遠景」はできるだけ後で描く
レンダリングとGPUデバッガ
● SDK付属の実機用GPUデバッガ
○ Unityも標準で対応
■ ビルド時に指定
○ 実行時のリアルタイム負荷グラフ
○ フレームをキャプチャ
■ RenderDocより詳細な内容を見られる
レンダリングとGPUデバッガ
● フレームキャプチャ時
○ 使用しているシェーダ、頂点、テクスチャ確認可能
○ ドローコール単位の消費時間を確認可能
■ 使い方の例:ポストエフェクトのエフェクト毎の処理時間
を測って伝え、「予算」の中に収まるようにデザイナ側
で検討
マスター提出前の
QAってどうすれば良いの?
QAをどう行うか?
● 普段から実機で動作を確認する
● QAは基本的に実機で行う
● チェック項目が定められているので、それに従う
○ きちんとチェックしないと通らないので注意
● 意外と時間を食うのでスケジュールにきちんと織り込む
まとめ
本日のまとめ
まとめ
● Nintendo Switch開発者はいますぐ
Unityを使用可能
● 困ったら開発者ポータル掲示板で質問
● Unity 5.6 で作る
● AssetBundle を必ず使う
CEDEC会場内
任天堂さまブース
Unityブース
でもご質問ください
ご清聴ありがとうございました!!
Q&A