読者です 読者をやめる 読者になる 読者になる

夏までにiPhone アプリつくってみっか!

趣味でiPhone/Androidアプリを開発し、日々勉強した事を書いています。オープンワールド系レースゲームをUnityで開発中です。

【Unity, Blender】LOD機能を使って自動的に表示ポリゴン数を節約

今回はUnityのLOD (Level of Detail)機能を使い、ポリゴンが細かいモデル、中間のモデル、荒いモデルを自動的に切り替えて不要なポリゴン数を抑える実験をしてみました。

LOD機能を使用するには、まずBlenderでポリゴン数の異なる複数のモデルを準備する必要があります。
Blenderには自動的にポリゴンを間引いてくれるDecimate Modifierというモディファイアーが用意されていますが、CR-Xの場合それほど上手には間引いてくれなかったので手動でポリゴンを削っていきます。
基本的にはDissolve Edgesでエッジを消して両隣のフェースを繋げていく作業を繰り返し、できるだけ元の形状を崩さぬように作業します。ポリゴンを消すことでUVが乱れるので形が崩れた部分は適宜Unwrapして配置し直します。

元の細かいモデルのTrisの数は7198です。
f:id:takujidev:20151027222925j:plain

中間のモデルでは3454まで減らしました。まだ違いはあまりありません。
f:id:takujidev:20151027223008j:plain

荒いモデルは1614です。元の1/4以下になっています。ここまで減らすと違いはわかりますが、遠く離れた時に表示されるモデルなので問題ありません。
f:id:takujidev:20151027223103j:plain

Blender上での複数のモデルの扱いですが、1つのファイル内の、異なるレイヤーに配置する方法をお勧めします。
そうしておくととUnityにインポートする時に自動でLODの処理をしてくれるので少し楽です。
レイヤーを分ける時はライトをそのレイヤーにも配置しないとマテリアル表示で真っ黒な車が出てきてしまうので要注意です。
私はこれでしばらく悩みました。
ライトを選択し、Mを押すと出てくるレイヤー選択画面でShiftを押しながら新たなレイヤーをクリックすると元のレイヤーと新しいレイヤー両方に同じライトが配置されます。Shiftを押さないとレイヤー間で移動してしまいます。

Emptyオブジェクトの子オブジェクトとして各LODのオブジェクトを入れたい場合は、BlenderでShift-Aで適当なEmptyオブジェクトを作り、Outliner上で子オブジェクトをEmptyオブジェクトにドラッグしParentingします。
BlenderのOutlinerの構造はUnityのHierarchyに同じ構造ででインポートされるので便利です。

例えば、車のモデルでタイヤを回すためにタイヤオブジェクトを参照する場合は各LODレベルの子オブジェクトを入れた親Emptyオブジェクトを参照すればOKです。
そうせずに、どれか1つのLODレベルのオブジェクトを参照すると、そのレベルの時だけタイヤが回転し、他のレベルでは止まってしまいます。

Blenderでこのようにオブジェクトを整理してみました。
f:id:takujidev:20151027224422j:plain

Unityにインポートために一番重要なのは、各オブジェクトの名前の後ろに_LOD0, _LOD1, _LOD2の識別子をつけておくことです。一番細かいモデルが_LOD0で荒くなるごとに_LOD1, LOD2と数字の部分を上げて行きます。
こうしておくとUnityがインポートする時に自動的にLODの設定をしてくれます。

このようにして作ったファイル(CR-X_LOD.blend)をUnityのプロジェクト内のフォルダーにコピーするとインポートされます。
インポートされたモデルをインスタンス化すると、Blenderでの構造と全く同じようにインポートされました。
f:id:takujidev:20151027224615p:plain

インスペクターで見るとCR-X_LODオブジェクトにはLOD Groupというコンポーネントが付いています。
LOD0, LOD1, LOD2と書かれたグラフをクリックすると、それぞれにアサインされているメッシュが表示されます。Blenderで_LOD(n)をつけ忘れるとここに出てこないので注意です。
f:id:takujidev:20151027225106p:plain

グラフの境界の部分を左右にドラッグすると画面上に表示されるオブジェクトの高さ(実際にはオブジェクトの周りに表示される四角の高さ)が画面の高さに対してどのくらいの比率(黄色矢印に対する赤矢印のパーセンテージ)になったら隣のレベルに切り替えるのかを調整できます。また、Culledの位置でモデルがどのくらいの大きさになったら表示をやめるか調整できます。
f:id:takujidev:20151027234030j:plain

カメラアイコンを左右にドラッグするとカメラがオブジェクトに近づいたり離れたりが離れたりしてLODレベルの切り替わりの様子がわかります。

グラフのカメラアイコンのグラフ上の位置と表示されるLODレベルが一致していない場合は、Quality Setting のLod Biasが1になっていないと思います。
これを1にするとちょうどグラフの境界で切り替わるようになります。
Lod Biasはプログラムを走らせる環境によりLODの切り替わり具合を調整するのに使います。個々のモデルのLOD Groupの設定を全て調整するのは大変ですが、Lod Bias設定を使用すれば一括で調整できます。
モバイルデバイスなど用のビルドではLod Biasを低めに設定することでLOD Groupでの設定値より早めに荒いモデルに切り替えポリゴン数を節約したりできます。

以上でLODの設定は完了です。
Blender側でファイルを分けてしまったなどの理由でインポートでうまくいかなかった場合はエンプティオブジェクトを作り、それにLOD Groupコンポーネントをアタッチして、グラフの各部分をクリックすると出るAddのところに対応するモデルをドラッグしていくことで手動でLODの設定ができます。手動で設定した時はカメラアイコンの動きと画面の動きが全く合わない場合がありますが、Recalculate:のBoundsボタンをクリックすると正しく追従するようになります。

実験結果です。
LODを使用しない場合は64.5kポリゴンのシーンです。
f:id:takujidev:20151027235619j:plain

LODを使用すると、同じシーンですが小さく表示される敵車の画面表示には荒いモデルが使用され、ポリゴン数が42.3kに抑えられました!
f:id:takujidev:20151027235752j:plain

ポリゴン数はかなり減りましたが、見た目には違いはほとんどありません。

【Unity】マテリアルの共有化でドローコール(Batches, SetPass Calls)が減ったかどうか検証

最初にモデリングしたAE86は車体各部を色毎にマテリアルを分けることで着色していました。
この方法は色艶の調整が楽なのですが、「ドローコールが増えて処理が重くなる」という情報を得ました。
そこで、2台目のCR-Xではできるだけマテリアルを共有し、着色、反射、鏡面、凹凸などはテクスチャで表現する方法に変えてみました。
今回は、実際にその効果があったのかどうかを検証したいと思います。

UnityのStatisticsウィンドウ(Gameビュー上部の枠のStatsをクリックして表示)には様々な情報が表示されますが、ゲームの処理の重さを測る指標としてBatches数、SetPass Calls数などがあります。
Unityの中の人によると、ドローコール数(=Batches数)は今やさほど問題ではなく、SetPass Calls数に気を配るべきだとのことらしいです。

参考:
GREE Tech Talk #07 ご来場ありがとうございました | GREE Engineers' Blog

比較のため、まずはAE86の各指標の数値がどうなっているか調べてみます。

f:id:takujidev:20151025115237p:plain

画面が真っ暗なのは純粋にモデルの部分だけの数値がみたかったからで、ライトやスカイボックスなどあらゆるものをOFFにしています。
ただし、地面がないと車が奈落の底へ落ちてしまうのでQuadを1枚敷いています。
Quad 1枚分の数値がこちらです。これを引いた値が純粋な車だけの数値となります。

f:id:takujidev:20151025115526p:plain

さて、最初のAE86と地面が表示されたスクリーンショットではBatches数が15、SetPass Calls数が9となっています。

AE86は車体と4本のタイヤ・ホイールの計5つのオブジェクトから構成されています。
車体は白、黒、窓の色、窓枠などのつや消し黒、テールランプの赤、オレンジの6つのマテリアル、タイヤ・ホイールは艶の違う2種類の黒の2種類のマテリアルを使用しています。
地面のマテリアルと合わせると計9種類のマテリアルが存在することになり、これはSetPass Callsの9と一致しています。

Batches数は各オブジェクトが持つマテリアル数の合計となるようです。
つまり、車体(6) + タイヤ(2) * 4 + 地面(1) = 15です。

次に、これがCR-Xではどのような結果になったのか、見てみたいと思います。

f:id:takujidev:20151025120315p:plain

Batches数が8、SetPass Calls数が3です。

減りました!

CR-Xは車体、4本のタイヤ・ホイール、ナンバープレート、パワーバルジ(ボンネット上の出っ張り)の7個のオブジェクとからなっています。
車体の大部分と他の全てのオブジェクトは1つのマテリアルを共有しています。唯一マテリアル分けたのは透明な材質にする必要があったヘッドライトカバーだけで、計2種類のマテリアルで構成されています。これに地面の1マテリアルを足すとSetPass Callsの3と一致します。

Batches数は本来は車体(2) + タイヤ(1) * 4 + バルジ(1) + ナンバー(1) + 地面(1) = 9なのですが、ナンバーとバルジのドローコールがバッチングにより1つにまとめられたためSaved by Batchingに1が計上され、Batches数は8となっています。

構成するオブジェクト数が違うのでBatches数の直接比較はできませんが、SetPass Calls数がAE86の1/3に減ったのでマテリアルを共有し、テクスチャで色分け、材質分けをした効果は大いにあったという結論となりました。

ただ、ひとつ気になったことがあります。
3角形ポリゴンの数を示すTris数なのですが、実際のモデルのポリゴン数と一致しています。
AE86のモデルのポリゴン数(Tris数)は4832で、Unity上のTris数は4.8k、CR-Xのモデルのポリゴン数は7198でUnity上の表示は7.2kとなっています。

私は今までUnity上のTris数は描画処理されているポリゴンの数だと思っていました。つまり、車の前面は底面など、反対側を向いていてBackface Cullingで描画されていないポリゴンの数が差し引かれ、モデルのポリゴン数の半分くらいの数が計上されているものだと勝手に考えていました。
しかし、この結果から考えるとBackface Cullingされているかどうかに関わらず、表示領域内のオブジェクトの全てのポリゴン数がカウントされているようです。
試しにナンバープレートのみを表示してみましたが、Backface Cullingは正常にされていて、向こうを向いている前のプレートは表示されず、カメラの方を向いている後ろのプレートだけが見えています。

f:id:takujidev:20151025123214p:plain

なお、表示領域外にありFrustum Cullingされたオブジェクトのポリゴン数は計上されません。

最後に、CR-Xがアキバの街を走る動画です。