【Unity】マテリアルの共有化でドローコール(Batches, SetPass Calls)が減ったかどうか検証
最初にモデリングしたAE86は車体各部を色毎にマテリアルを分けることで着色していました。
この方法は色艶の調整が楽なのですが、「ドローコールが増えて処理が重くなる」という情報を得ました。
そこで、2台目のCR-Xではできるだけマテリアルを共有し、着色、反射、鏡面、凹凸などはテクスチャで表現する方法に変えてみました。
今回は、実際にその効果があったのかどうかを検証したいと思います。
UnityのStatisticsウィンドウ（Gameビュー上部の枠のStatsをクリックして表示）には様々な情報が表示されますが、ゲームの処理の重さを測る指標としてBatches数、SetPass Calls数などがあります。
Unityの中の人によると、ドローコール数(=Batches数)は今やさほど問題ではなく、SetPass Calls数に気を配るべきだとのことらしいです。
参考：
GREE Tech Talk #07 ご来場ありがとうございました | エンジニアブログ | GREE Engineering
比較のため、まずはAE86の各指標の数値がどうなっているか調べてみます。
画面が真っ暗なのは純粋にモデルの部分だけの数値がみたかったからで、ライトやスカイボックスなどあらゆるものをOFFにしています。
ただし、地面がないと車が奈落の底へ落ちてしまうのでQuadを1枚敷いています。
Quad 1枚分の数値がこちらです。これを引いた値が純粋な車だけの数値となります。
さて、最初のAE86と地面が表示されたスクリーンショットではBatches数が15、SetPass Calls数が9となっています。
AE86は車体と4本のタイヤ・ホイールの計5つのオブジェクトから構成されています。
車体は白、黒、窓の色、窓枠などのつや消し黒、テールランプの赤、オレンジの6つのマテリアル、タイヤ・ホイールは艶の違う2種類の黒の2種類のマテリアルを使用しています。
地面のマテリアルと合わせると計9種類のマテリアルが存在することになり、これはSetPass Callsの9と一致しています。
Batches数は各オブジェクトが持つマテリアル数の合計となるようです。
つまり、車体(6) + タイヤ(2) * 4 + 地面(1) = 15です。
次に、これがCR-Xではどのような結果になったのか、見てみたいと思います。
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は正常にされていて、向こうを向いている前のプレートは表示されず、カメラの方を向いている後ろのプレートだけが見えています。
なお、表示領域外にありFrustum Cullingされたオブジェクトのポリゴン数は計上されません。
最後に、CR-Xがアキバの街を走る動画です。
https://itunes.apple.com/jp/app/toraberushutingu-retorona/id917570972?mt=8&uo=4&at=10laCt
https://itunes.apple.com/jp/app/beecluster-wu-liaono-zongsukurorushutingugemu/id663801586?mt=8&uo=4&at=10laCt
【Unity】テクスチャのインポート設定で色々な見た目の問題を解決
今回はUnityのテクスチャインポート設定がモデルの表示品質にどのように影響するか検証してみました。
なお、テスクチャのインポート設定は、プロジェクトパネルでテクスチャを選ぶとインスペクタに表示されまます。
その1
前回、ノーマルマッピングを施したナンバープレートがUnity上で見るとグニャグニャなのが気になったのでまずはこれを修正したいと思います。
ご覧のとおり、クラッシュして潰れたナンバープレートを叩いて直したような悲惨な感じになっています。
これを新車同様にするためには、テクスチャの取り込み設定でCompressedになっているのをTruecolorに変更します。
その結果、このように綺麗な平面が得られました。
なお、文字のフチがギザギザなのはテクスチャの解像度が足りないせいなのでこれでは改善されません。
Truecolorは、テクスチャの圧縮を使わない設定なのでメモリ使用量が増加します。圧縮フォーマットのPVRTC 4bitsから非圧縮のRGB24 bitになるとこのテクスチャのメモリの使用量は6倍になります。
表示品質を取るかメモリを節約するか悩ましいところです。
将来的にメモリ使用量が厳しくなったら圧縮に戻す可能性ありです。
その2
次にテクスチャの色漏れの問題を解決したいと思います。
白いバックランプをよく見ると分かりますが、上の方が赤色ににじんでいます。
これはAlbedo用テクスチャを圧縮をしない設定にするか、Mip Mapの生成を解除すると治りました。
なお、Mip Mapの設定は標準ではインスペクタに表示されず、Texture TypeをAdvanceに設定することで表示されるようになります。
デフォールトではGenerate Mip Mapsのチェックボックスがチェックされていますので、チェックを外します。
すると、このようににじみがなく綺麗に表示されます。
Mip Mapは何段階かに縮小したテクスチャをあらかじめ用意しておくことでテクスチャを縮小するときの品質やパフォーマンスが向上する技術らしいですが、今回は逆に色がにじんで品質が低下結果となりました。
Mip Mapを使わない場合は小さいテクスチャが生成されなくなるのでその分若干のメモリの節約になります。
テクスチャの非圧縮よりは悪影響が少なそうなので、今回はMip Mapの設定を変えました。
その3
最後にスペキュラーマッピングの不具合です。
非常に見えにくいですが、黄色の丸をつけた部分に艶感が違う四角い部分があります。
このボツボツはいたるところにあって、太陽が反射するとボディが全体的にザラついた質感に見えます。
これはスペキュラーマップ用テクスチャの圧縮によるノイズによるもので、インポートでTrueColor設定にすると消えました。
以上、3つの不具合をテクスチャのインポート設定で解決しました。
表示品質は良くなったのですが、メモリ使用量の増加やパフォーマンスの低下がゲームにどの程度影響するか現時点では不明なので、チューニングの過程で設定を戻す可能性はあります。
https://itunes.apple.com/jp/app/toraberushutingu-retorona/id917570972?mt=8&uo=4&at=10laCt
https://itunes.apple.com/jp/app/beecluster-wu-liaono-zongsukurorushutingugemu/id663801586?mt=8&uo=4&at=10laCt
