しゅみぷろ読者になるしゅみぷろプログラミングとかこの広告は、90日以上更新していないブログに表示しています。まとめ(1日目)UnityはじめにUniteで聴講させていただいたものをとりあえず整理してまとめておきます。2日分まとめて書こうと思ったんですがめちゃくちゃ長くなりそうなので分割することにしました。本記事では1日目の内容を書いていきます。個人的に興味深かった講演については後日もっと深く掘り下げようと思っています。今回は大雑把にどんなことをお話しされていたか等を残しておきます。講演の資料はこちらからDLできます。モバイル端末向けのUnityアプリケーションの最適化実践テクニックモバイル端末のアプリケーション最適化テクニックについての講演でした。この講演で強調されていたのは「良いデータを取ること」でした。ここで言う良いデータとは、プロファイラ等を用いて計測されるパフォーマンス測定データのことで、これらのデータを正確に取得し、リソースを喰い潰している原因を特定することが最適化の第一歩となります。よるパフォーマンスの低下について説明されていました。boxingが発生するコードを記述しない)といった感じで、普段からこういったことを意識してコードがかけるかどうかが重要そうです。ファイルインポート設定また、外部からインポートするファイルについても注意が必要だと説明していました。enabledは(必要がなければ)falseにしておくべきです。アセットのインポートについてはAssetPostProcessorを継承することで独自に拡張することができます。UI等で利用しているテクスチャ以外は基本的にMipmapを生成すべきです。GCとManagedHeapManagedHeapとGCについても説明されていました。.NETで開発している時と注意点としてはあまり変わらない部分もあるかなと思いましたが、気をつけておくべきことについて書いておこうと思います。ManagedHeapは最初、ある程度の領域を確保しておき、その領域からオブジェクト生成の際のメモリを割り当てます。割り当てるメモリ領域がなくなってしまった場合、このHeap領域が整理され、フラグメンテーションが解消されます。それでも確保するべきメモリが足りない場合、Heap領域が拡張されます。Heap領域が大きければ大きいほど1回のGC.Collectによるレイテンシも大きくなります。ゲームにとっては致命傷になりかねません。Allocの項目は全て無くすくらいの勢いで最適化に臨むべきです。最適化の方法はStringの利用を避けるBoxingを避ける再利用可能なコレクションを利用する(新しいコレクションをどんどん生成しないようにする)といったものが挙げられます。テキストパースによるロード時間JsonやXMLのパースには時間がかかる(内部でリフレクションを使っていることが多い)ため、ロードに時間がかかります。UnityのBuiltin型のJsonUtilityクラスを使うことで高速化できます。テキストファイルをScriptableObject等にしてしまうことで読み込み時間を少なくすることができます。UnityのデータタイプはWorkerスレッド上ではシリアライズできないので、別途Threadを生成してUnityのデータをデシリアライズし、高速化を図る、というようなことが出来ません。ResourcesフォルダからAssetを排除し、AssetBundleを使うようにすることでも高速化を図れます。Resourcesのことは忘れましょう!ローカルなデータもAssetBundleでロードするようにします。データの扱いがコード上でも一本化されて外部リソースを使う際にも煩わしさが軽減されて個人的には嬉しいことです。ランタイムCPU例えばマテリアルのシェーダープロパティのアクセスによくStringを用いますが、Hashでのアクセスの方が望ましいです。何回もこのStringで呼び出す場合に、一回だけHash値を求めて以後はそれを使ってプロパティにアクセスするわけです。Manipulation、BoxingはメモリだけでなくCPU時間をも喰らいます。特定の文字列操作はかなり低速です(RegExps,String.Start(End)With,etc..)。既存のプロジェクトでは、CPUが処理に時間をかけている部分を見つけ出し、そこから改善していくことが大切です。Unityグラフィックス最新機能ガイドUnityの最新のグラフィックスについての講演でした。5以降のUnityでは「絵作り」がかなり楽しくなってきました。その際に利用できるImageEffectの紹介や、Unity5.4からの新機能などが盛り込まれた非常に有意義な講演でした。Rendering5.4からの新機能で、MainThreadだけでなくWorkerThreadでもレンダリングさせるようにしたそうです。スライドを見るとグラフが載っていますが、かなりパフォーマンスが改善しています。Effectsオープンソースで使えるImageEffectです。Aberrationsレンズで覗き見るようなスクリーン効果を表現し、画面周囲にぼやっとした感じのなにがしを書くといった感じでした。MapperDynamicなGIが不要な場合にかなり使える表現になりそうです。ビルド時にライトマップを生成し、そのテクスチャを貼り付けてしまおうというものです。ライトマップの生成はRaytraceによって行われていて、ライトからRayを飛ばし、ヒットした場合にテクスチャにライトをベイクします。ハードウェア性能を引き出して60fpsを実現するプログラミング・テクニック個人的にかなり好きな内容でした。Vitaで60fps出るようなゲームを実際に作って、工夫した点を簡潔にまとめてくださっていました。ゲームはこちらで公開されています。後日公開されているプロジェクトを詳細に見ていこうと思っていますが、講演で述べられていたことだけさらっとまとめておこうと思います。理解が間違っている部分があるかもしれませんのでご了承ください。ゲームロジックを別スレッドで行わせるMainThreadにかかる負荷を減らすために、WorkerThreadを生成し、このThreadでゲームロジックを処理しているようです。WorkerThreadの問題点として、ほとんどのUnityのAPIが使えないことが挙げられます。PhysicsやColliderも使えないため「なければ作ればいい!」の精神でこれを実装していったそうです。全て完璧に実装する必要はなく、ゲームで必要な見せ方ができる程度に適当に作ればいいのでそこまで重く考える必要もないはずです。MainThreadに情報を渡す経路には、ダブルバッファを使っています。WorkerThreadでは、ゲーム処理をUpdateする部分とこのバッファを更新するRenderUpdateなる2つのフェーズから成り立っています。MainThreadはUpdateされたバッファを参照し、必要なUnityAPIをCallする仕組みです(見てないので恐らくですが)。GPUを多用するエフェクトはGPUを多用することでCPUになるべく負荷をかけないようにし、パフォーマンスを発揮できるようにする試みです。ImageEffectはもちろんですが、Meshのverticesを更新してパーティクル効果を出す「GPUパーティクル」について紹介されていました。動的なメモリを確保しないstructを多用し、オブジェクトは事前確保、使い回しすることでGCのCollectを避けたそうです。Heap領域はなるべく使わないようにし、Heapの拡張が起こらないようにしています。学校では教えてくれないアセットバンドルのしくみみんな大好きAssetBundleの仕組みまでしゃぶらせてくれる夢のような講演でした。今後はResourcesも使わなくなり、AssetBundleに一本化していくことになりそうなのでゲームを個人で開発していてABはあまり触ったことがない・・・というような方でも今後触れる機会が増えていくのではないでしょうか。アセットバンドルおさらいアセットを含めたコンテナで、これを後から配信してゲーム内で展開し、利用することができます。Unityのランタイムで利用するデータはほとんどがアセットバンドルにできます。シリアライズされた複数のアセットを内部に含むことができますが、1つに含まれるファイル数が増えれば検索に時間がかかるようになってしまうので注意が必要です。観点から一長一短、といった感じでした。この2つの長所を持つハイブリッドな圧縮フォーマットによって、今後は更に使い勝手が良くなりそうです。先にも少しあげましたが、圧縮フォーマットがLZ4に変更されます。以前のABでは圧縮フォーマットはLZMAで、伸張処理にファイル全体が必要だったのですが、チャンクが揃ったオブジェクトから順次アクセスすることが可能になりました。UnityWebRequestWWWを使うとManagedのHeapを拡張してしまう可能性がありました。これを回避するには、WWWを使わずにWebClientとかを使ってアセットをダウンロードしてどっかに保存する仕組みを作る必要があったのですが、この用途にUnityWebRequestが使えます。このクラスは直接WWWに置き換わる機能を提供してくれるそうです。Unity上級者を目指すなら知っておくべきデバッグテクニック集テラシュールブログでおなじみの方の講演でした(そうとは知らずに講演に来たのでビックリしました・・・)。バグへの向き合い方などを再度確認し、早期発見のための基本的な手順をおさらいできる、とても楽しい内容でした。MacでVS使いたいですね。仮想環境でVSを動かすこともできますがセットアップが面倒な上にVS用slnの構築を行うエディタ拡張等を用意する必要があったりデバッガを利用する場合リモートデバッガを使う必要があったりと怠いです。VS使うならWindowsで開発していくのが一番という結論。デバッグの手順バグを正しく定義するバグを再現するバグが発生する箇所を見つけ出す問題を修正するといった手順で行っていきます。バグではなく仕様であれば修正の必要はないのでみなさんCSのバグ対応には最大限ゴネてみることが大切です。バグ確認の流れ走査方法、デバイスの接続等の確認(入力の問題)パラメーターの差し替え(データの問題)プログラムを確認(ソースコードの問題)OSやプラットフォームの問題?(ルールの問題)といった流れでバグを確認していきます。パラメーターやらプログラムのロジックが間違ってるのでここまできたら観念して修正にあたりましょう。絞り込みの手順バグ発生箇所の絞り込みについてです。問題周辺コードが呼ばれているかDebug.Logを呼び出してみる。Debug.logger.logenabled=falseで一括非表示にできる。パラメータは意図したとおりのものが入力されているかAssertを使う。IsNotNullでもインスタンスがない場合があるので注意。TestRunnerを書いて実行しちゃうといい。デバッグを容易にする。問題発生時の値は正しいかDebug.LogやAssertで値をみる。デバッガで処理を止めて確認したりとか。バッガを利用できない(?)って言ってた。処理の実行順は意図したとおりか式は正しいかというような感じで絞っていくといいっぽいです。)はてなブログをはじめよう!es_programさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。