キーワード	説明	コルーチンでいうと
`async`	awaitを使うメソッドにつける必要があるキーワード	-
`await`	非同期(async)メソッドを呼び出し、その完了まで実行を中断するキーワード	yield return
`Task<T>`	awaitするためのクラス。GetAwaiterを実装している	IEnumrator

私は非同期にしたい関数にasyncつける〜とか思っていたのですが全く違いました(笑)

async/awaitは非同期の処理を待つための仕組みなんですね。

コルーチンとの対応の説明を聞いてすんなり納得しました！

コルーチンより嬉しいこと

コルーチンを使っている方はわかると思いますが、

・コルーチンでは非同期で処理した結果(返り値)を受取るのが難しい。(IEnumrator.Currentでアクセスするしかない)

・コルーチンはネストしていくと扱いが難しくなるため、実装が複雑になる。

・非同期処理内ではUnity APIを使用できない。

とあまり柔軟な書き方ができないです。

Task+awaitではそれが可能になるため嬉しいということですね！

f:id:yutt1:20180513150131j:plain f:id:yutt1:20180513150134j:plain

セッションではこの他にスレッドを管理するSynchronizationContextについての説明もされてました。

あまり深くは言及されませんでしたが、UniRxなどを使って実装する時などは、実行スレッドを意識する必要があるので確認しておくとよさそうです！

「60fpsのその先へ！スマホの物量限界に挑んだSTG「アカとブルー」の開発設計」

【Unite 2018 Tokyo】60fpsのその先へ！スマホの物量限界に挑んだSTG「アカとブルー」の開発設計 from UnityTechnologiesJapan002

www.slideshare.net

スマートフォンゲーム「アカとブルー」は大量の弾幕が飛び交うSTGなのですが、それを60fpsで実現するために行った最適化実装について解説されました。

ただ、正直Unityのパフォーマンスを引き出す実装というよりかは、Unityの機能をなるべく使わないという実装のため、初心者の方はAdvancedな内容として見たほうがよいです。

最適化の基本

最適化	理由
起動元の一つ以外で`Start()`や`Update()`を実装しない。	Unityは`Start()`や`Update()`が空実装であっても呼んでしまうのでコストがかかるため。
`Monobehavour`いらないなら付けない	`Transform`や`GameObject`の参照コストが発生するため。
`calss` < `struct` `List`<`Array` `多次元配列[,]` < `ジャグ配列[][]`	参照速度が早いため。但し`List<struct>`の`foreach`など値渡しのオーバーヘッドには注意。
オブジェクトプーリング	生成コストやメモリアローケートを抑えるため。
コンポーネントキャッシュ	Unity2017時点では参照コストは低くなったが、まだキャッシュした方が良い。
定数キャッシュ	`Vector3.zero`などは生成コストが発生するため

この他に、Vector3の計算系は重いため独自実装を行ったとのことでした。

ちなみにオブジェクトプーリングの実装は非常に勉強になるので、一度確認すると良いです。 github.com

さらにそれを解説した本も出ていて、私も発売日に買って読みましたが、Githubと合わせて読むと理解が深まります。 bootlegstore.stores.jp

アーケードスタイルSTGを重視したCollision実装

Unityのコリジョン判定では、メインスレッドと同期しないため人の目に写ったものと現象と厳密には異なります。

アカとブルーではゲームデザインを重視したため、接触判定を実装したが、その要求がないなら自前実装する必要ないとのこと。

f:id:yutt1:20180513231258j:plain

1パスでSprite描画できるP-MAPブレンド

通常、爆発系のエフェクトなどは、半透明+加算合成によって複数のテクスチャを合成して作られます。

半透明と加算はスプライトのバッチングは行われないため、複数描画した場合、その数分SetPassCallが増加します。

この問題に対して、事前乗算という手法を用いると大量に描画しても1Passで描画できるというものです。

詳しくは↓

[Unity]加算と半透明を1パスにするP-MAPブレンド実用例 - Qiita

私はこれは知らなかった手法であり、嬉しい発見でした！

他にも幾つかゴリゴリな最適化実装について解説されてます。

「そろそろ楽がしたい！新アセットバンドルワークフロー&リソースマネージャー詳細解説」

【Unite 2018 Tokyo】そろそろ楽がしたい！新アセットバンドルワークフロー&リソースマネージャー詳細解説 from UnityTechnologiesJapan

www.slideshare.net

新機能であるAddresstable AssetsとResource Managerについての解説セッションです。

今まで複雑だったAssetBundleの取扱いがとても楽になるのはもちろん、単純にリソース管理においても効率化できそうでとても楽しみです！

現在はPreview版で、2018.2から利用可能になるとのことです。

リソース管理の進化点

この新たなリソース管理フローはResources管理のような簡単さを目指したとのことでした。 f:id:yutt1:20180513233655j:plain

Addresstable Assetsと一言で表してもツールとしてはラベルやグループなど新たな概念を扱うため、スライドも合わせて確認すると良いと思います。 f:id:yutt1:20180513235226j:plain

機能	説明
AssetReference	アセットのアドレスをInspectorから簡単に指定できるためのクラス
参照カウント	参照カウントによってリソースやインスタンスのロードや破棄ができる
グループ	アセットの配置場所やパッキング方法、ロード方法を決めるカテゴリ
コンテンツカタログ	アドレス、ラベル、グループの対応を保持するJsonデータ
ラベル	アドレスに付与するタグ的な機能
プロファイル	ロード場所やビルド場所を、develop, test, releaseなど用途毎に設定できる
プレイモード	エディター実行時のリソースのデータロード仕方を指定できる
RM Profiler	アセットバンドル、アドレス付きアセットのロードとアンロード、参照カウント数、ロード方式を可視化

Resource Managerの仕組み

Addressable Assetsがアセットにアドレスを付与することで、アドレスによるロードや管理が出来るようにするシステムでした。

それに対し、Resource Managerはアセットを様々な場所から、非同期でロード・インスタンス化・管理・アンロードを出来るようにするシステムになります。

Resouce ManagerにはResource LocationとProviderという仕組みが用意されており、これがリソースの扱いをかなり柔軟にしてくれます。

f:id:yutt1:20180513235736j:plain

機能	説明
Resource Location	リソースの所在地や依存関係情報を提供
Resource Provider	リソースのロード・アンロード機能を提供
SceneProvider	シーンのロード・アンロード機能を提供
Instance Provider	インスタンスの生成・管理機能を提供

このProviderの嬉しいところは独自管理方法にしたい際などに、各種Providerにその処理を実装することで実現できることです。

f:id:yutt1:20180514000241j:plain

とても楽しみな機能ですが、その分フローをしっかり理解する必要があるので、要チェックですね！

他の要確認セッション

運営中コンテンツにおける大型アップデート成功のための考え方とUnity最適化手法

【Unite 2018 Tokyo】スクリプトによるTimelineがっつり拡張入門

https://www.slideshare.net/UnityTechnologiesJapan/unite-2018-tokyotimeline-96459645

【Unite 2018 Tokyo】スクリプタブルレンダーパイプライン入門

【Unite 2018 Tokyo】C# Job SystemとECS（Entity Component System）解説

Day3感想

Day2と同様に既存の実装において新しい発見はあまりなかったです。

ただ、TimelineやAddresstable Assetsなど機能面での発見が多く、改めてチェックする必要がありました！

以上Uniteレポートでしたノシ

配信アーカイブ

https://www.twitch.tv/videos/259277629

・新機能Shader Graphを使えばプログラミング無しにシェーダーが作れるようになります！

・スクリプトによるTimelineがっつり拡張入門

・60fpsのその先へ！スマホの物量限界に挑んだSTG「アカとブルー」の開発設計

・Windows Mixed Reality 最新アプリ開発情報～HoloLens からVRまで～

・Unityの開発サイクルとバグへの取り組みについて

・カスタムシェーダーでモバイルでも最先端グラフィックスな格闘ゲームを！

・そろそろ楽がしたい！新アセットバンドルワークフロー&リソースマネージャー詳細解説

・Unityにおける疎結合設計～UIへの適用事例から学ぶ、テクニックとメリット～

2018-05-13

【Unity】Unite2018 Day2 レポート

Unity Unite

2018/05/08(火) Unite 2日目行ってきました。 f:id:yutt1:20180512230835j:plain

1日目のレポートはこちら yutt1.hatenablog.com

2日目からは、ホールに分かれてセッションが行われます。朝から注目のセッションばかりでとても楽しかったです^^

ちなみに、2日目の個人的ベストセッションは【Unite Tokyo 2018】誘導ミサイル完全マスターでした！

聞いた講演を中心に勉強になったものを書いていこうかと。

ComputeShaderを駆使した1000発が飛び交う弾幕の実装「誘導ミサイル完全マスター」
ミリシタで13人ライブを可能にした最適化「なんとっ！ユナイト！ミリシタをささえる『ＡＫＡＮＥ大作戦』とは？」
- サブメッシュ統合によるドローコール削減
- CommandBufferによるマテリアルLOD
「実践的なパフォーマンス分析と最適化」
- AnimationでのCPU最適化
データドリブンな実装を！「「リトルチャンピオンズ」癖になるアクションゲームの開発事例」
- コマンドパターンベースなアーキテクチャ
新機能UI Elements「エディター拡張マニアクス2018」
- UI Elements
他の要確認セッション
Day2感想
配信アーカイブ

ComputeShaderを駆使した1000発が飛び交う弾幕の実装「誘導ミサイル完全マスター」

【Unite Tokyo 2018】誘導ミサイル完全マスター from UnityTechnologiesJapan

www.slideshare.net

最初は、誘導ミサイルの実装をシェーダーで実装することで、高負荷な表現を行うといったAdvancedセッションです。

誘導ミサイルの計算をGPUで処理させ、演出の描画などをCPUで担う場合、どのようにしてUnityで実装するかを非常にわかりやく解説されました。

また、UnityのPhysics機能を使わず、物理学に則った説明であるため、誘導ミサイルだけでなく、物理実装全般に役立つような実践的な内容でした。

ミサイルの実装の基本

誘導ミサイル程度であれば、応用(ゆらぎや着弾時刻ずらし等)がきくため、実装にはPhysicsやLerpは使用しない方がよいとのことでした。

運動方程式に則り、シンプルに実装ができます。

追尾レーザー f:id:yutt1:20180512235231j:plain 誘導ミサイル f:id:yutt1:20180512235318j:plain

ハードウェアのための最適化実装

昔々のハードウェアでは厳しい制約があり、それを工夫により乗り越えていました。

制約	工夫
整数しか使えない	4096を1.0として扱う (固定小数点方式)
割り算が重い	掛け算の度に4096で割る (12bitシフトは高速)

それを今回の実装にも適用することで最適化をはかるというものです。

制約	ミサイル実装での工夫
整数しか使えない	⊿t(`Time.deltaTime`)を1として扱う
割り算が重い	2のべき乗時刻のみ速度を計算しなおす(割り算をシフト演算で行う)

ComputeShaderへの応用

ここまでC#で実装していた内容をComputeShaderで実装することでGPUで計算させ、高速化を行いました。

しかし、GPUで実装する際にはいくつか考えなければならない問題があり、一つ一つ解説されました。

目標物の位置情報が必要
ミサイルは1つずつ発射されが、GPUは常に並列で計算する
描画処理はCPUで行う
目標物を失った際の処理
目標物に当たった際のCPUへの通知

他にもいくつか最適化実装を行っており勉強になりました。 Githubでサンプルプロジェクトも公開されてるので要確認です。 github.com

ミリシタで13人ライブを可能にした最適化「なんとっ！ユナイト！ミリシタをささえる『ＡＫＡＮＥ大作戦』とは？」

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

www.slideshare.net

セッションでは、開発のスケジュールや歌い分けの実装などミリシタの裏側が軽く紹介された後に、ミリシタで行った最適化について説明されました。

ミリシタの最適化では、クオリティを下げないことをポリシーに、なるべくエンジニアで頑張るという精神で行っていったそうです。

サブメッシュ統合によるドローコール削減

基本的にDrawCallはAtals化やMaterialを共通にするこでまとめて描画されるため削減できます。しかし、SubMeshを越えてのまとめはされないという問題があります。 f:id:yutt1:20180513011624j:plain

この問題に対しDirectXやOpenGLなどのネイティブな実装では、インデックスバッファーを一つにまとめ、インデックスの範囲指定で、部分 or 全体を描画するらしいです。

Unityの描画実装はブラックボックスなため実際の描画システムは分かりません。しかし、根底はネイティブの実装と変わらないはずだということで、全 SubMesh をマージした SubMeshを追加することでSubMeshの統合を可能にしたとのこと。 f:id:yutt1:20180513012330j:plain

結果として、1体あたりドローコールは25→17に。

CommandBufferによるマテリアルLOD

描画距離によって、マテリアルの描画内容を変えることで負荷を軽減させるというもの。

これを実現するには、サブメッシュ単位のビジブル制御が必要となるのだが、CommandBufferを使用することで非常に簡単に実現できたとのこと。

どちらもネイティブ実装の知識を生かした高速化ということで、自分に足りない部分な内容で勉強になりました！

「実践的なパフォーマンス分析と最適化」

【Unite Tokyo 2018】実践的なパフォーマンス分析と最適化 from UnityTechnologiesJapan

www.slideshare.net

Unityにおける最適化が網羅的に解説されました。

AnimationでのCPU最適化

個人的に興味深かったのは、UnityのアニメーションシステムはAnimation Curveの数が大きいほど最適化されるという内容でした。

内容	結果
100Animation, 12Curve	Legacy 4ms Generic 9ms
100animation, 640Curve	Legacy 19ms Generic 13ms Humanoid 26ms

検証の結果、Animation Curve 300個以上になるとLegacyよりGenericの方が速くなるとのこと。

したがって、複雑でないAnimation(Textureのアニメーションとか)ならLegacy Animationの方がパフォーマンスが出るということでした。

他にも2018.1からAnimatorBindingが入るため、再生成時ののコストが抑えられるようになるなど、勉強になる情報が多かったです！

データドリブンな実装を！「「リトルチャンピオンズ」癖になるアクションゲームの開発事例」

【Unite Tokyo 2018】「リトルチャンピオンズ」癖になるアクションゲームの開発事例 from UnityTechnologiesJapan002

www.slideshare.net

「リトルチャンピオンズ」のゲーム特性上、リプレイと途中復帰が求められるということで、実装設計やデータ設計などについて解説されました。

コマンドパターンベースなアーキテクチャ

リプレイや途中復帰などを実現するには、ユーザーが行った行動や結果を保持する必要があります。

そこで、ユーザー操作をコマンドで表現することで、リプレイや途中復帰などの際に、コマンドを流し込むことで再現させるというものでした。

f:id:yutt1:20180513015207j:plain

このアーキテクチャのよいところはロジックとデータが分離しているため、テストしやすい点にあると思いました。

また、StageEditor時にもキャラや予測線などの実装は流用できるため、インゲームに依存しない実装は勉強になりました。 if (isStageEditor)と書いてスパゲティになるのは辛いですからね(僕はやらかしました)

余談ですが、コマンドデータのセーブフォーマットが気になり質問した所、独自のバイナリでSerialize/Deserializeしてるとのことでした。JsonやMessage Packとかとの性能比較はしたわけではないが、セーブファイルの軽さを選んだとこと。

新機能UI Elements「エディター拡張マニアクス2018」

【Unite 2018 Tokyo】エディター拡張マニアクス2018 from UnityTechnologiesJapan

www.slideshare.net

2015年頃からの3年間で実装されたEditor拡張についてと、今後の実装予定の内容について説明されました。

内容としては、まだPreview版だけどすごく楽しみな機能が多く、その中でもUI Elementsは非常に興味深かったです。

UI Elements

現状のUnityEditorのUI構成はIMGUIというものであり、OnGUIに直感的に書いていくものです。そのためUIが複雑になるほど、コードの記述も大変になります。

現在のUnityでは出来ることが増えたため、IMGUIでのEditor拡張はメンテナンス性や拡張性が弱いです。

そこで、新たなUIシステムとしてRMGUIであるUI Elementsを開発中とのこと。

UI Elements自体はWebのHTMLと基本構造は似ており、HTMLを書くように構成できるとのこと。 f:id:yutt1:20180513020701j:plain

個人的に、描画、構成、処理とファイルを分割出来るのは拡張性、メンテナンス性が上がるため非常に良いと思いました。

楽しみなUI Elementsだが、ユーザーが使えるのは2019.xの予定とのこと！

他の要確認セッション

『崩壊3rd』開発者が語るアニメ風レンダリングの極意の極意

Day2感想

最適化系のセッション中心に回ったが、2017.xからの機能周りで出来ることが増えたというのが分かり良かったです。

グラフィック関連やVR関連のセッションが多く、そちらはあまりチェックしていないので、個人的にはもう少し発見があると嬉しかったです。

配信アーカイブ

https://www.twitch.tv/videos/258911177

・『崩壊3rd』開発者が語るアニメ風レンダリングの極意

・ユニティちゃんトゥーンシェーダー2.0使いこなしスペシャル～こだわりの活用法を紹介します！～

・実践的なパフォーマンス分析と最適化

・パーティクル・マニアクス

・その最適化、本当に最適ですか！？～正しい最適化を行うためのテクニック～

・アーティストがUnityでサクッといいビジュアルを作るテクニック講座

・Unity for ディープ・ラーニング：ツールキット『ML-Agents』のご紹介