この記事は KLab Creative Advent Calendar 2019 の20日目の記事になります。

こんにちは。KLab株式会社クリエイティブ部TA(テクニカルアーティスト)グループのmasahideと申します。

今年の5月には新人TAの業務内容についてブログを書かせていただきました。
今回は携帯端末ごとの描画スペックについてお話ししたいと思います。

概要

近年多くの種類のモバイル端末が世に出回っていますが、各モバイル端末がどれほどの描画能力(画面にモデルやエフェクトを表示する力)を持っているのかご存知の方は少ないと思います。

この記事では各モバイル端末ごとに、実際どの程度のモデルやエフェクトを描画する能力があるのか紹介し、どのような視点でリソースの削減をしていけば良いのか書いてゆきます。

今回はクリエイティブブログですので、デザイナー / アーティストさん向けにできる限り分かりやすく記載しています。

プログラマーの方から見たら省略しすぎていると感じる点があるかもしれませんが、ご了承ください。

「デザイナーだから端末の描画スペックを知ってもしょうがない」と思った方もいらっしゃると思いますがそんなことはありません。

ゲームの処理負荷軽減のためにモデル、エフェクトの作り直し・調整をした経験のあるデザイナーさんも少なくないと思います。

端末ごとの描画スペックを事前に把握しておくことで、例えばモデルやエフェクトを制作する際にポリゴンの限界数やボーンの最大インフルエンス数(1つの頂点あたりに影響するボーンの数のこと)などがなんとなく分かるようになり、アセットの作り直しによる工数を一定削減することができるようになります。

テスト環境詳細

ゲームエンジン：Unity 2018.4.2f1
グラフィックスAPI：OpenGL ES2.0

テスト端末紹介

今回は下記の3種類の端末にて検証を行いました。
左から、GALAXY S3, GALAXY S5 Active, Google Pixel 3 です。

端末名	チップ	発売年	備考
GALAXY S3	Snapdragon S4	2012年	Lowスペック代表
GALAXY S5 Active	Snapdragon 801	2014年	Middleスペック代表
Google Pixel3	Snapdragon 845	2018年	Highスペック代表

モデル

1.ポリゴン数(トライアングル)

それでは、まず各端末でどれほどのポリゴンを描画する能力があるのか検証してゆきます。

今回は画像のような1本の円柱を、UnityのStandardシェーダで表示するだけのプロジェクトで計測しました。

端末名／球体のポリゴン数	20万	35万	60万	150万	350万	500万	800万	1,500万
GALAXY S3	60FPS	56FPS	30FPS	19FPS	測定不能	測定不能	測定不能	測定不能
GALAXY S5 Active	60FPS	60FPS	60FPS	50FPS	30FPS	15FPS	測定不能	測定不能
Google Pixel3	60FPS	60FPS	60FPS	60FPS	60FPS	60FPS	54FPS	30FPS

図1.端末ごとの表示ポリゴン数とFPSの対応表(最大1,500万ポリゴン)

図2.端末ごとの表示ポリゴン数とFPSの対応表(最大800万ポリゴン)

図の1と2はどちらも端末ごとの表示ポリゴン数とFPSの関係をグラフ化したものです。

図1はGoogle Pixel 3を、図2はGALAXY S3とGALAXY S5の確認をしやすいように、表示する最大値の調整をしております。

上記の計測結果から端末ごとに表示できるポリゴン数に大きな開きがあることが分かります。仮に30FPSで動作するゲームを作成する場合、GALAXY S3は60万ポリゴン、GALAXY S5 Activeは350万ポリゴン、Google Pixel3は1500万ポリゴンを最大で表示できるが分かります。

実際のゲーム制作では、テスト環境よりも複雑な描画計算を行うことが多いため、大抵は使えるポリゴン数が大幅に減ってしまいます。

仮に、検証時の10倍処理負荷が重いGPU処理を行っている場合には、Google Pixel3であれば150万ポリゴンの描画までが30FPSで動作することができるという計算になります。

2.ボーンアニメーション

次はボーンアニメーションと処理負荷の関係について検証してゆきます。

今回はテスト用に円柱モデル(ポリゴン数4万)を8本準備し、インフルエンス数やボーンの構造が違うものをいくつか用意して検証を進めました。

このようなポリゴン数で検証を行ったのには理由があります。

• 今回ローエンド端末として設定したGALAXY S3
  

  • 60FPSを安定して描画することができるポリゴン数が総合計32万ポリゴンであること
    

• 今回ハイエンド端末として設定したGoogle Pixel 3
  

  • ボーンアニメーションを行った際に60FPSを割り始めるラインが総合計32万ポリゴンであること
    
    

つまり、上記の検証結果からハイエンド端末であってもボーンアニメーションの負荷によって60FPSを安定して描画できなくなる値として、一定の指標になることを証明するためです。

インフルエンス数2の場合

端末名／円柱一本のボーン数	0	50	400	1,000	5,000	9,000
GALAXY S3	60FPS	57FPS	52FPS	30FPS	10FPS	測定不能
GALAXY S5 Active	60FPS	60FPS	60FPS	55FPS	29FPS	15FPS
Google Pixel3	60FPS	60FPS	60FPS	59FPS	52FPS	32FPS

インフルエンス数4の場合

端末名／円柱一本のボーン数	0	50	400	1,000	5,000	9,000
GALAXY S3	60FPS	56FPS	51FPS	28FPS	8FPS	測定不能
GALAXY S5 Active	60FPS	60FPS	60FPS	55FPS	27FPS	12FPS
Google Pixel3	60FPS	60FPS	60FPS	59FPS	49FPS	30FPS

今回の計測では、GALAXY S3が1000本、GALAXY S5が5,000本、Google Pixel3が9,000本まで30FPSを維持することができました。

ゲーム開発において一つのモデルに1000本以上のボーンを使用することはほとんどないかもしれませんが、現行のハイエンド端末でも1000本以上のボーンを使用したアニメーションを8回おこなえば、60FPSを安定して描画できなくなることが分かりました。

※髪の毛やスカートなど、ボーンオブジェクト自体をリアルタイムにシミュレーションして揺らす、いわゆる「揺れ物」などはボーンの負荷がもっと上がります。

3.モデルまとめ

今回の検証では、ポリゴン数 / ボーン数 / インフルエンス数の3項目について検証し、
ポリゴン数 ＞ ボーン数 ＞ インフルエンス数の順に処理負荷に影響がありました。

しかし上記の結果だけで、「ポリゴン数だけ気にして作れば問題は起こらない」と結論を急いではいけません。

なぜなら、ゲームの要件・描画技法などの要因によってこれらの処理負荷は大きく変化してしまうためです。

デザイナーの方はプロジェクトのできるだけ早い段階で、そのゲームで表現したいことを明らかにし、そのうえで実現するための最適なレギュレーションをプログラマーやTAの方と策定してゆくのが良いと思います。

エフェクト

次はエフェクトの処理負荷について検証しました。

今回はUnityのパーティクルシステム(shurikenのCPUパーティクル)を使用して、
大量のパーティクルエフェクトを作成し、計測を進めてゆきます。

端末名／パーティクル数	5,000	8,000	10,000	50,000	100,000	500,000
GALAXY S3	59FPS	45FPS	40FPS	10FPS	測定不能	測定不能
GALAXY S5 Active	60FPS	60FPS	60FPS	30FPS	10FPS	測定不能
Google Pixel3	60FPS	60FPS	60FPS	60FPS	50FPS	8FPS

図1. 端末ごとの表示パーティクル数とFPSの対応表

1.エフェクトまとめ

上記の計測結果から、30FPSで動作するゲームを作成する場合、GALAXY S3は2万、GALAXY S5 Activeは4.5万、Google Pixel3は30万粒のパーティクルを表示できることが分かりました。

モデルのポリゴン表示数について触れたところと同様に、あくまでこれらは最大数のため、実際にゲームを制作する際にこれほどの数は表示できないと思います。

ゲーム内で使用できる現実的な数に関しては、できるだけ早い段階でプログラマーやTAの方に相談をするようにしましょう。

まとめ

今回の記事を読んでいただいた方の多くは、端末ごとのスペックの大きな開きに驚かれたのではないでしょうか？今回の検証を通じて、私も驚くことが多かったです。

端末の種類によっては簡単にFPSが落ちてしまうため、下記4点を意識して制作を進めてゆけるといいと思います。

1.プロジェクトの早い段階で、プランナーとゲームの表現や端末を選定する。

2.やりたい表現を実現するため、プログラマーやTAの方と一緒にレギュレーションを選定する。

3.プログラマーやTAの方に処理負荷の計測を定期的に行ってもらう。
・レギュレーション違反をしているリソースデータがないか確認するため。
・想定よりも重いリソースデータ(ボトルネック)がないか確認するため。

4.ボトルネックになっているリソースデータの修正方法を、プログラマーやTAの方と決定する。
・必要以上にリソースデータの削減をしてしまわないために、必ずプログラマーや　TAの方に相談をするようにしましょう。

最後までご覧いただきありがとうございました。