simplestarの技術ブログ

目的を書いて、思想と試行、結果と考察、そして具体的な手段を記録します。

Unity:頂点法線の計算と事前設定の速度の違い

2週間前に、Unityのパフォーマンス測定の差先端について調べた記事を書きました。
simplestar-tech.hatenablog.com

ここで調べた手法で、頂点生成系のプログラムのいくつかの負荷試験を行ってみます。
タイトルの通り、頂点法線の計算をランタイムで行うのと、事前に設定するのとでどれくらいパフォーマンスが変わるのか見ていきたいとおもいます。

負荷が計測できる程度に前回の頂点生成で作る三角柱を並べます。(15 x 15 x 15 個、計3375)
f:id:simplestar_tech:20180922081047j:plain

処理はインスタンス生成とメッシュ作成に分けましたが、それぞれで高負荷が発生しました。
まずはインスタンス生成時のタイムラインを確認してみました。
f:id:simplestar_tech:20180922081503j:plain
CreateInstance という Unity 側に予約されている部分が大部分を占め、続いて mesh オブジェクト作成と GCAlloc にも犯罪的な処理時間を要していました。

メッシュ生成のタイムラインを確認すると次の通り
f:id:simplestar_tech:20180922081616j:plain
mesh に頂点を設定、インデックスを設定、UVを設定、メッシュを割り当てといったことに、ちりも積もれば山となるという感じで、短い計算が重なって全体的な処理時間が大きくなるという結果でした。
頂点法線の計算はほとんど時間を要していないことがわかります。

こういうことがわかるのは本当、プロファイラの良いところだと思います。

タイトルの通り、RecalculateNormals を使うか、そのまま設定するかでどのように変化するかを示して終わりたいと思います。

まずは RecalculateNormals を使う場合 PlayerLoop は total 72.97 ms 要していました。
ここで頂点法線を事前に決めて与えるように修正しました。

set normals に 9ms ほど要していました。PlayerLoop は total 72.60 ms 要しています。
ほとんど変化していないですね。

次の記事で、インスタンス化する数を減らす工夫をしてみます。