[Unite2018] 運営中コンテンツにおける大型アップデート成功のための考え方とUnity最適化手法
公式サイト
http://events.unity3d.jp/unitetokyo2018/session-lineup.html#session66
講演者
金井 大 (株式会社Cygames)
稲田 健人 (株式会社Cygames)
SlideShare
http://tech.cygames.co.jp/archives/3128/
概要
- 大型アップデート実現に効果的な3Dグラフィック表現
- アップデート規模と実現難易度が比例傾向
- コンテンツと大型アップデート施策の概要
- 大型アップデートで行われた3Dグラフィクスのクオリティアップの詳細
- 運営中コンテンツの大型アップデートを成功させる考え方、Unityを使った開発の進め方
内容
- コンテンツと大型アップデート施策の概要
- 適用事例紹介
- 2015年リリースゲーム
- 60fpsを担保しつつ3Dグラフィクス表現
- 2017/6に大型アップデート
- 3ヶ月で開発
- Unite2016で講演済 [Unity 3D 考え方] 検索
- なぜ大型アップデートを行うのか
- 3Dグラフィクス品質の底上げ
- 行ったこと
- 高品質版の作成(2D, 3D)
- それぞれ3段階の設定
- 軽量版
- 限界までスペックを落としたもの
- 標準版
- ミドルレンジ端末
- 高品質版
- ハイエンド端末
- 軽量版
- それぞれ3段階の設定
- 高品質版の作成(2D, 3D)
- 詳細
- イメージエフェクトのクオリティアップ
- キャラクタのクオリティアップ
- 画面解像度
- MSAAの導入
- ETC2フォーマットの導入
- OpenGLES3.0対応
- イメージエフェクト
- シェーダの対応が中心
- 既存アセットの修正量は少ない
- 処理負荷を基準に判断できる
- 軽量版のパイプライン
- UnityのレンダリングはCamera基準
- 軽量版
- ForwardBase
- 標準版
- UpdateDepthTexture
- ForwardBase
- ImageEffect
- 描画頂点数は2倍弱に増える
- 高品質版
- プロジェクションシャドウ、ミラー処理等でカメラ追加
- プロジェクションシャドウ
- Unity標準のソフトシャドウはモバイルで利用できないので、自前で実装
- ジャギーをなくす
- ミラー
- ミラー用カメラを用意
- 鏡面レンダリング、プロジェクションで、地面への映り込みをリアルタイム処理
- Replaced Shadersを利用
- ライトシャフト
- 深度値を参照しブラーをかける
- 散乱光の表現
Legacy Image Effect
>SunShafts
をベース- サンプル数やブラーのかけ方をカスタマイズ
- レンズフレア
- Unity標準のレンズフレアで対応
- 光源が隠れた際にフレアが正しく消えないと不自然に見える
- キャラクタは人型のみ
- 雛形を作って量産
- 問題があるデータは順次修正
- ティルトシフト
- 画面の上下、左右などをぼかす機能
- Image Effectのみでかなり柔軟な表現が可能
- DOFと異なり深度値情報が不要、頂点負荷に優しい
- Legacy Image Effectをベースにカスタマイズ
- まとめ
- ImageEffectは採択しやすい、処理負荷のみ着目できる
- 頂点スペックには配慮が必要
- すべてを自作する必要はない
- キャラクタのクオリティアップ
- ライティングアルゴリズム変更の課題
- 軽量化のためライティングを行っていない
- diffuseテクスチャに陰影を書き込んでいた
- ライティングを強化
- 軽量化のためライティングを行っていない
- 既存アセットの修正には作業コストと管理コスト
↓ - 以下のもの導入
- リム
- 環境マップ
- スペキュラ
- ○ キャラクタ、カメラ移動に応じた変化がある
- ○ 費用対効果が高い
- ノーマルマップ
- △ UVの大幅修正が必要
- トゥーンレンダリング
- △ テクスチャ陰影とのバッティングする要素が多い
- 制御マップの導入
- 専用のテクスチャを用意
- RGBチャネルで強度を制御
- 正しいライティングを行うための課題
- 正しい法線情報が必要
- 3D標準はライティングをしていないので、法線情報がない
- 正確には、アウトラインに調整した法線情報しかない
- Unityメッシュデータは2つの法線情報を保持できない
- 2つの法線を保持させる方法
- Asset Import時に処理
- UV2とUV3に法線情報を入れたFBXを別途用意
- インポート時にUV2とUV3をtangentへ移動
- オーサリングの課題と解決
- 今まではMaya上の見た目がUnityと概ね一致していた
- ライティングアルゴリズムの変更により一致しなくなった
- アーティストにとって非効率
↓
- アーティストにとって非効率
- シェーダを組み直し
- まとめ
- ライティングアルゴリズム変更の課題
- 画面解像度
- 標準解像度ではMSAAx4を適用
- MSAA導入時の注意点
- テクスチャのサンプリング範囲が広がる
- UVレイアウトによってはノイズが表示される
↓ - テクスチャを修正して対応
- 背景はノイズが目立つ箇所のみパディングを4ドットに拡張
- キャラクタはUV
- まとめ
- 解像度変更は採択しやすい
- パディングは統一ルールを設ける
- ジャギーの緩和自体は効果がある
- ETC2フォーマットの導入
- なぜ必要?
- テクスチャ圧縮時に発生するバンディング問題を解決したい
- 繊細な表現に問題がある
- グラデーション
- バンディングの解決方法
- TETC2は圧縮時間と品質をバランス良く担保
- なぜ使っていなかった?
- OpenGLES2.0ではETC2は拡張扱い
- メモリ使用量が6倍になる
- Unity5.1.2では例外対応できない
- OpenGLES2.0ではETC2は拡張扱い
- ETC2フォーマットを導入するために
- Unityのバージョンアップをする
- まとめ
- ETCはテクスチャ品質が低い
- ETC2を採用するには動作保証する端末を適切に行う
- なぜ必要?
- 適用事例紹介
- 運営中Unityバージョンアップを成功させるための考え方と開発の進め方
- Unity 5.1.2 -> 5.4.5へバージョンアップ
- 今回のバージョンアップの前提
- リリースして2年、バージョンを上げたことがない
- バージョンアップポリシーは大きく2つ
- 安定版を利用、アップデートは最小限
- 積極的に最新版に合わせる
- 今回は前者
- どのようにすすめるか?
- どのバージョン、どの順番、どのように混乱を避けるか
- まずバージョンの選定を行う
- ブランチ運用の構成図
- 運営
- release
- develop
- アップデート
- develop
- develop_rich すべての作業が終わったらdevelopにマージ
- Unity5.4.5 develop_richにマージ
- 運営
- コーディングのポリシー
- いつでもバージョンを切り替えができるようにする
#if UNITY_5_4_OR_NEWER
#else
...
- シェーダのAutoUpgrade対応
- AutoUpgradeを無効にする
- シェーダもバージョン分岐
- AssetBundleの互換性を保つ
- 意図しないシェーダを含むことがある
- シェーダに互換性がなかった
- シェーダの見つけ方
- チェックツールの作成
- 単体テストできる環境の用意
- シェーダをAssetBundleから分離する
- シェーダをAssetBundle化すれば分離できる
- 意図しないシェーダを含むことがある
- いつでもバージョンを切り替えができるようにする
- 大型アップデートを成功させる考え方、Unityを使った開発の進め方
- 開発したものが運営に対してどういう影響をあたえるかを考える必要
- 増えたリソース数7000件
- 増えたAssetBundle数2150件
- ほんの少しの懸念も大きな影響を与える可能性
- 懸念点
- AssetBundleのビルド時間増大
- 実際は大きな問題にならなかった
- 並列ビルドをしていたため
- ビルド済みのManifestは再ビルド必要ない
- アセットをカテゴリごとに管理し、ビルド不要なカテゴリは事前にManifestをコピー
- アップデートで増加したAssetBundleを新カテゴリとすることで、ビルド時間の改善が可能
- Assetインポート時間の増大
- UnityCacheServerが導入されておらず、以前からインポート時間が問題になっていた
- マテリアルを動かす際に問題
- 再インポートを明示的に行いキャッシュを更新すればよい
- 新規リソース追加による管理コスト増大
- 今回追加したすべてのファイルの末尾に一律の単語をつけて管理
- ex) folder_A_hq
- 今回追加したすべてのファイルの末尾に一律の単語をつけて管理
- AssetBundleのビルド時間増大
- まとめ
- どう進めれば安定した運営を提供し続けられるか
- 開発したものが運営に対してどういう影響をあたえるか
- 開発の段階ですべて潰して運営に導入する
- 開発したものが運営に対してどういう影響をあたえるかを考える必要