こんにちは。開発企画室の佐島です。

はじめに

3月25日（水）、グリー主催の技術勉強会GREE Tech Talkが開催されました。
7回目となる今回のテーマは「Unity Performance Casual Talk」。
過去、どちらかと言えばインターネット業界よりのテーマで開催してきましたが、今回のテーマはゲーム業界向け。
それもあって、会場の7割近くがゲーム業界関係者という、いつものGREE Tech Talkとはちょっとだけ違う雰囲気の中での開催となりました。

セッション概要

当日行われたセッションの模様をダイジェストでお届けします。

『Live2Dの描画の裏側の話』 阿曽 直貴（株式会社Live2D）

最初にご登壇頂いたのは株式会社Live2Dの阿曽さん。Live2Dとはイラストをそのまま動かすことができるツールのことで、詳しくはスタッフブログを見てくださいとのことでした。

まず最初にLive2Dの技術的な解説から。
基本的に3D技術の延長上に成り立っているとのことですが、下記のように3D側からするとマニアックすぎて情報が少なかったり、最適化されていない部分だったりしたそうです。
3Dとの違い
* 頂点の形状変形を常に行っている点
* 半透明オブジェクトが多い点
* メッシュでリアルタイムクリッピングが必要な点
* テクスチャのクオリティが高い点

そしてLive2DをUnity上で動かすためにどんなことをやったかという話に移ります。(ちなみにUnity3.5時代の話でした)
まず最初にネイティブプラグインを使ってUnityの描画にOpenGLで割り込むということをされたそうです。しかしこれは、Unityの挙動を推測しながらの開発だったためUnityがバージョンアップすると動かなくなるなどの問題を抱えていて、高速で安定していたものの、メンテナンスが大変だったとのこと。
そこでスクリプトから高速にメッシュを描画するという方向にきりかえたそうです。
ドローコール削減のためMesh.CombineMeshesでメッシュを結合したところ、ドローコールを実質1にできたとのことでした。
ドローコールが減っただけで本当に速くなったのか実際にUnityのプロファイラで検証したところ、倍以上速くなったとのことです。

最後に、当てはまる状況は少ないがArray.Reverseを使うことでパフォーマンス上の影響が出る場合があるのできちんと何をやっているかを考えながら使ったほうが良い、プロファイラに頼らず管理クラスを作った方が便利、といったパフォーマンスのためのTipsで締めくくられました。

『Unity カジュアルゲーム・ケーススタディ』稲森 亮介（グリー株式会社）

続いて弊社エンジニアの稲森亮介によるUnity カジュアルゲーム・ゲーススタディ。4月リリース予定の「Amy the Starry Archer」というカジュアルゲームを開発するにあたって、パフォーマンスの観点で気をつけた話でした。

まず最初にTarget Frame Rateについて。今回のゲームは操作パネルで照準を操作するというもので、フレームレートが高いか低いかで操作感度や難易度に影響するため、端末に応じてベストなフレームレートが出せるようにしたとのこと。
実際には動的にフレームレートを落とす、ある程度下がったらカメラのfarClipを落とす、と言った処理を行ったそうです。
続いて雲の描画について、オーバードローをいかに減らしたかという話。雲を遠景用と中景用にわける、雲に最初からグラデーションをかけてライティングをやめる、などの工夫をしたという説明がありました。

次にライティングに対する工夫について。Asset Storeから入手した3D背景素材はライトマップに使われた光源が削除されていたため、ライトマップを直接編集することで対応した、また洞窟ステージでは動的にライトマップを解除したりしたそうです。
また、ゲームの特性上背景をじっくり見るようなものではないためライトマップの解像度を落とすのも有効だったとのこと。
スクリプトの最適化では、一般的に重たいと言われているものを実測。結果敵キャラの管理に使っていたFindObjectsOfType()が重かったので自前のリスト管理で回避したということでした。

最後は敵キャラの動きを設定するツールを作成した話。生産性はあがったものの、学習コストもそれなりにかかってしまったということでした。

スライド：Unity カジュアルゲーム・ケーススタディ

『ドローコール伝説の終わり 〜新たなるパフォーマンスの道を求めて〜』大前 広樹（ユニティ・テクノロジーズ・ジャパン合同会社）

最後に、Unityの中の人、大前さんが登壇されました。

ドローコールを減らせ！とよく言われるが減らせばよいと言うものなのか？そもそもドローコールとは何なのか？という所から解説が始まりました。
パフォーマンスが悪いのはCPUかGPUのどちらかが遅いことが原因で、UnityにおけるドローコールとはなんとなくCPU側の描画処理全体だと思われがちだが、実際にはCPU側からGPU側に描画内容を渡すための呼び出しのことで、OpenGLのglDrawElements()などが該当する。
そしてこのGPUへ渡す処理はドライバーの進化でどんどん高速化されていて、モバイルにおいても今後は問題にならなくなるだろうということです。
ではどこが重いのかというと、描画のための各種状態の変更やそれに伴うメモリコピーなどを行っているあたりで、これに対する新しい指標がSetPassということでした。

ドローコールをStatic Batchingなどを通して減らすことは、必ずしも描画の最適化にはつながらず(まとめても、それほど速度が上がらない)、むしろ、むやみに巨大なメッシュを作ってしまうと、オクルージョンカリングに悪影響を及ぼす可能性もあります。このような点からも今後は"Draw calls"よりも”SetPass calls"に気を配るべきとのことでした。
GPU側の描画の問題はRendererがいっぱい（ピクセル描画が重い）か、Tilerがいっぱい（頂点量が多すぎ）のどちらかで、問題の確認にはXcode & Instrumentsを使うか、GPUベンダーのプロファイラを使うと良いとのこと。
次にSetPassを6回から60回に変えてiPhoneでテストして描画のコストが倍になるというデモがありました。実際にSetPassが増えていることが視覚的にわかるようになっていて、ここを減らすことで描画コストが下がることがわかりました。

最後に以下のような結論で締めくくられました。
* 描画が重い＝ドローコールではない
* 重いドローコールと重くないドローコールを切り分ける
* 重い原因はUnityのプロファイラ、フレームデバッガーやGPUベンダーのプロファイラを使って解決

ゲーム自慢

今回は懇親会中にプロジェクターにお客様のゲームを投影し、それを見ながらお酒を飲もうというプチイベントを企画しました。要はアンカンファレンスなのですが、ゲーム業界での呼び名がわからなかったのでゲーム自慢ということに。
実際にはゲームだけじゃなくアプリやイベントの告知などなんでもアリになりました！

みくちゃ @sorasu2113	桜花一門
FLIGHTPENGUIN 宮下	ドラゴンイーター @kamoyugo
LOCUS Tracer 大濱	OcumaRion！ @mizuki_izuna
てっく	@lycoris102
Unite 非公式アフターパーティ 2015 Tokyo @Takaaki_Ichijo	POLYHEDRON COLLECTION @YO1KOMORI

最後に

改めまして、お忙しい中ご来場頂きましたみなさま、ニコ生をご視聴頂きましたみなさま、並びに快く登壇をして頂きましたスピーカーのみなさま、ゲーム自慢にご参加頂いたみなさま、本当にありがとうございました。

参考

togetter：GREE Techtalk#7 – Unity Performance Casual Talk -
公式サイト：GREE Tech Talk #07『Unity Performance Casual Talk』
ATND：GREE Tech Talk #07「Unity Performance Casual Talk」- #greetech07 -