えいごのおべんきょう：Unity Gear VR Gameのパフォーマンスを搾り出せ

対訳形式で翻訳してみるその2です。

Blog — Squeezing Performance out of your Unity Gear VR Game | Oculus

Squeezing Performance out of your Unity Gear VR Game
Unity Gear VR Gameのパフォーマンスを搾り出せ

So you’ve decided to build a VR game in Unity and have settled on the Samsung Gear VR as your target platform.
UnityのVRゲームをビルドしようと思い、プラットフォームをSamsugGearVRに据えようとしています。

Getting it up and running on the device was easy enough, but there’s a problem—the frame rate is just too low.
立ち上げて走らせることまでは十分に簡単でした。が、問題が発生します――フレームレートが激低すぎる。

Your reticle snaps and sticks, there are flickering black bars on the sides of your vision, and motion looks like somebody just kicked the camera operator in the shins.
レティクル(焦点板)は途切れたり止まったり、視界の端に黒い枠がチラチラしたり、動作はカメラ操作担当が誰かに脛でも蹴られたようだったり。

You’ve read about how important it is to maintain a solid frame rate, and now you know why—in mobile VR, anything less than 60 frames per second doesn’t just look bad, it feels bad.
そして徐々に固定フレームレートの維持の重要性を理解していき、知ることになるでしょう――mobileVRにおいて、60fpsを切ることが単に"見た目が悪くなる"のではなく、"気持ち悪くなる"ということを。

Your high-end PC runs the game at about 1000 frames per second, but it sounds like a jet engine and actually levitates slightly when the fans really get going.
ハイエンドPCではそのゲームが1000fpsで動いても、それはジェットエンジンのようなものであり、ファンによりまさに若干浮かされているようなものです。

What you need is a way to optimize your masterpiece to run on a mobile chipset.
今必要なものは、あなたの最高傑作をモバイルチップセット上で動かすために最適化するための技です。

This series of articles is designed to help you do just that.
この一連の記事はその一助となるべく企画されました。

Part 1: The Gear VR Environment and Traits of Efficient VR Games
パート1: GearVRの動作環境と効率的なVRゲームのための特性

This isn’t an all-encompassing expose on performance optimization for the Gear VR—it’s more of a quick start.
これは網羅的にGearVRの性能最適化を羅列するものではなく、クイックスタート（初歩ガイド）になります。

In this first post we’ll discuss the Gear VR hardware and traits of a well-designed mobile VR application.
この最初の記事ではGearVRのハードウェアや良デザインなモバイルVRアプリのための特性について検討します。

A follow-up post will cover performance improvement for apps you’ve already built.
追記記事では、既にビルドしたことがあるアプリへのパフォーマンス改善についてカバーします。

I’ve elected to base this article on the behavior (and quirks) of Unity, as it seems to be very popular amongst Gear VR developers.
この記事は、おそらくGearVR開発者で最大手であろうUnityにおける（クセも含めた）挙動をベースにします。

Still, the concepts presented here should apply to just about any game engine.
なお、記事内の概念的なものは他のゲームエンジンでも転用できるものでしょう。

Know Your Hardware
ハードウェアを知るべし

Before you tear your project apart looking for inefficiencies, it’s worth thinking a little about the performance characteristics of mobile phones.
クソ挙動を目の当たりにしてプロジェクトを引き裂く前に、少し携帯電話の性能特性について考えてみましょう。

Generally speaking, mobile graphics pipelines rely on a pretty fast CPU that is connected to a pretty fast GPU by a pretty slow bus and/or memory controller, and an OpenGL ES driver with a lot of overhead.
一般にモバイルのグラフィックパイプラインは超高速CPUに依存し、超高速なGPUに超"低速"なバスやメモリコントローラと、そしてオーバーヘッド過多なOpenGL ESドライバに接続しています。

The Gear VR runs on the Samsung Note 4 and the Samsung Galaxy S6.
GearVRはSamsungNote4とSamsungGalaxyS6上で動作します。

These two product lines actually represent a number of different hardware configurations:
これら2つの製品は数多くの異なるハードウェア構成の実に典型なものとして挙げられます：

- The Note 4 comes in two chipset flavors.
Note4は2つのチップセットを元にしています。

- Devices sold in North America and Europe are based on Qualcomm’s Snapdragon chipset (specifically, a Snapdragon 805), while those sold in South Korea and some other parts of Asia include Samsung’s Exynos chipset (the Exynos 5433). The Snapdragon is a quad-core CPU configuration, while the Exynos has eight cores. These devices sport two different GPUs: the Adreno 420 and Mali-T760, respectively.
北米や欧州で販売された機器のQualcomm社 Snapdragonチップセット(具体的にはSnapdragon805)、韓国やその他アジア各国で販売されたSamsung社 Exynosチップセット(Exynos 5433)。SnapdragonはクアッドコアCPU、一方でExynosは8コアCPUです。
(訳注：sport→恐らくsupportの誤り？)
これらのデバイスは2つの異なるGPUに対応しています：それぞれAdreno420とMali-T760です。

- The Note 4 devices are further segmented by operating system. Most run Android 4.4.4 (KitKat) but Android 5 (Lollipop) is now available as an update on most carriers around the world. The Exynos-based Note 4 devices all run Android 5.
Note4のデバイス群はさらにOSによって切り分けられます。
大半はAndroid4.4.4(KitKat)ですが、Android5(Lollipop)がアップデートにより大半のキャリアで広く利用可能になっています。
ExynosベースのNote4は全てAndroid5で動かすことができます。

- The Galaxy S6 devices are all based on the same chipset: the Exynos 7420 (with a Mali-T760M8 GPU). There is actually a second version of the S6, the Galaxy S6 Edge, but internally it is the same as the S6.
GalaxyS6シリーズは全て同じチップセットです： Exynos7420(GPUはMali-T760M8)
S6の次のバージョン(GalaxyS6 Edge)は出ました。が、内部的にはS6と同じです。

- All Galaxy S6 devices ship with Android 5.
GalaxyS6シリーズは全てAndroid5で出荷されています。

If this seems like a lot to manage, don’t worry:
対応が大変そうだと感じるでしょうか、ご心配なさらず：

though the hardware varies from device to device, the performance profile of all these devices is pretty similar (with one serious exception—see “Gotchas” below).
ハードウェアがデバイス間で異なっても、性能プロファイルはかなり似たものです（１つの深刻な例外を含む――下記"仕様"へ）。

If you can make it fast on one device, it should run well on all the others.
1つのデバイスでさえ高速化できれば、他でも動作するでしょう。

As with most mobile chipsets, these devices have pretty reliable characteristics when it comes to 3D graphics performance.
大半のモバイルチップセットでは、これらの機器は3Dグラフィックパフォーマンスにおいてかなり信頼できる性能があります。

Here are the things that generally slow Gear VR projects down (in order of severity):
以下は一般にGearVRのプロジェクトを遅延させる原因です(重要性の順)：

- Scenes requiring dependent renders (e.g., shadows and reflections) (CPU / GPU cost).
シーンが依存したrenderを必要とする(例、影や反射) (CPU/GPUコスト)

- Binding VBOs to issue draw calls (CPU / driver cost).
ドローコールの元となるBinding VBO(Binding Vertex Buffer Object) (CPU/ドライバコスト)

- Transparency, multi-pass shaders, per-pixel lighting, and other effects that fill a lot of pixels (GPU / IO cost).
透過、マルチパスシェーダ、ピクセル単位ライティング、その他大量のpixelを塗りつぶすエフェクト群 (CPU/IOコスト)

- Large texture loads, blits, and other forms of memcpy (IO / memory controller cost).
巨大なテクスチャ読み込み、blits(Bit Block Transfer/オフスクリーン描画?)、その他memcpy形式(IO/メモリコントローラコスト)

- Skinned animation (CPU cost).
スキンアニメーション(CPUコスト)

- Unity garbage collection overhead (CPU cost).
UnityのGCオーバーヘッド(CPUコスト)

On the other hand, these devices have relatively large amounts of RAM and can push quite a lot of polygons.
一方、これらのデバイスは比較的多めのRAMが積んであり、大量のポリゴンを送ることが可能です。

Note that the Note 4 and S6 are both 2560×1440 displays, though by default we render to two 1024×1024 textures to save fill rate.
注意として、Note4とS6はいずれもディスプレイが2560×1440に対し、テクスチャはデフォルトでは描画速度を維持するため1024×1024が2枚になっています。

Know the VR Environment
VR環境を知るべし

VR rendering throws hardware performance characteristics into sharp relief because every frame must be drawn twice, once for each eye.
VRレンダリングはハードウェア性能特性を浮き彫りにします。毎フレームに1度で両目用に2倍描画するためです。

In Unity 4.6.4p3 and 5.0.1p1 (the latest releases at the time of this writing), that means that every draw call is issued twice, every mesh is drawn twice, and every texture is bound twice.
Unity4.6.4p3と5.0.1p1(この記事における最新版)において、全てのドローコールが2倍呼ばれることになるため、全てのメッシュは2回描画され、テクスチャも2回バインドされます。

There is also a small amount of overhead involved in putting the final output frame together with distortion and TimeWarp (budget for 2 ms).
最終的に出力されるフレームをまとめるまでに、歪みやタイムワープ(2ms計上)を伴う若干のオーバーヘッドも発生します。

It is reasonable to expect optimizations that will improve performance in the future, but as of right now we’re stuck with drawing the whole frame twice.
これは将来的なパフォーマンスが改善するであろうことを期待しておくことにして、今のところは毎フレームを2倍描画しておくことにしましょう。

That means that some of the most expensive parts of the graphics pipeline cost twice as much time in VR as they would in a flat game.
これは、通常のフラットなゲームのそれと比べて、VRにおいてはグラフィックパイプラインコストで最も高いものはその2倍時間がかかるということです。

With that in mind, here are some reasonable targets for Gear VR applications.
加えて念頭に置いておくこととして、Gear VRアプリケーションではいくつかの目安があります。

- 50 — 100 draw calls per frame
フレーム当たり50～100ドローコール

- 50k — 100k polygons per frame
フレーム当たり5万～10万ポリゴン

- As few textures as possible (but they can be large)
テクスチャはできるだけ少なめに(ただし大きくても可)

- 1 ~ 3 ms spent in script execution (Unity Update())
スクリプト実行に1～3msかかる(UnityのUpdate())

【絵】

This frame is about 30,000 polygons and 40 draw calls.
この絵では3万ポリゴン程度で40ドローコールです。

Bear in mind that these are not hard limits; treat them as rules of thumb.
覚えておいてほしいこととして、これは絶対的な制限項目ではないことです。経験則として扱ってください。

Also note that the Oculus Mobile SDK introduces an API for throttling the CPU and GPU to control heat and battery drain (see OVRModeParams.cs for sample usage).
同様に注意してほしいこととして、OculusMobileSDKでは熱やバッテリー消耗の調整のためのCPUおよびGPUスロットル(※速度調整)のAPIを持っています。(サンプル OVRModeParams.cs)

These methods allow you to choose whether the CPU or GPU is more important for your particular scene.
これらのメソッドは特定のシーンでCPUとGPUのどちらがより重要か選択させる余地を持たせます。

For example, if you are bound on draw call submission, clocking the CPU up (and the GPU down) might improve overall frame rate.
例えば、ドローコールが問題となった際、CPUクロックを上げる(あるいは下げる)ことでフレームレートを全般的に調整できます。

If you neglect to set these values, your application will be throttled down significantly, so take time to experiment with them.
これらの数値を見過ごすと、アプリケーションの処理が著しく下がることがあるかもしれません。試してみる時間を取ってみてください。

Finally, Gear VR comes with Oculus’s Asynchronous TimeWarp technology.
最後に、GearVRはOculus社の非同期タイムワープ技術(Asynchronous TimeWarp technology)が入っています。

TimeWarp provides intermediate frames based on very recent head pose information when your game starts to slow down.
タイムワープはゲームが遅延しはじめた際に直近の頭部位置に基づいて中間フレームを提供します。

It works by distorting the previous frame to match the more recent head pose, and while it will help you smooth out a few dropped frames now and then, it’s not an excuse to run at less than 60 frames per second all the time.
これは頭部位置に適するよう直近のフレームを歪ませ、所々抜けてしまったフレーム間をつなぐことで、60fpsを切る言い訳を延々としなくてもよくなります。

If you see black flickering bars at the edges of your vision when you shake your head, that indicates that your game is running slowly enough that TimeWarp doesn’t have a recent enough frame to fill in the blanks.
もし頭を振った際に視界の端で黒いチラチラとした枠が見える場合、タイムワープがそのブランクを埋められるほどの十分なフレームがない程、そのゲームはかなり遅いということを示しています。

Designing for Performance
パフォーマンスのための設計

The best way to produce a high-performance application is to design for it up-front. For Gear VR applications, that usually means designing your art assets around the characteristics of mobile GPUs.
ハイパフォーマンスなアプリを制作する最適な方法は、前もってデザインすることです。GearVRアプリケーションにおいては、アートアセットをモバイルGPUの特性で設計することを一般に意味します。

Setup
セットアップ

Before you start, make sure that your Unity project settings are organized for maximum performance.
まず始めに、Unityのプロジェクトセッティングがパーフォーマンスを最大化するよう構成されているか確認してください。

Specifically, ensure that the following values are set:
特に以下の設定がされているか確認しましょう：

- Static batching

- Dynamic batching

- GPU skinning

- Multithreaded Rendering
マルチスレッドレンダリング

- Default Orientation to Landscape Left
Default OrientationをLandscape Leftに設定
　⇒端末を回転させた際の画面の向きを固定する - テラシュールブログ

Batching
バッチ

Since we know that draw calls are usually the most expensive part of a Gear VR application, a fantastic first step is to design your art to require as few draw calls as possible.
GearVRアプリにおいてドローコールが一般に最もコストが高いことはご承知の通りなので、素晴らしい第一歩としてはアートが出来る限り少ないドローコールになるように設計することです。

A draw call is a command to the GPU to draw a mesh or a part of a mesh.
ドローコールはGPUへのコマンドであり、メッシュやメッシュの一部を描画します。

The expensive part of this operation is actually the selection of the mesh itself.
この操作で最もコストが高い操作は実はメッシュの選択自体です。

Every time the game decides to draw a new mesh, that mesh must be processed by the driver before it can be submitted to the GPU.
ゲームは常時、新たなメッシュの描画を決め、そのメッシュはドライバによって事前にGPUに書き込まれたものが処理される手筈になっています。

The shader must be bound, format conversions might take place, et cetera; the driver has CPU work to do every time a new mesh is selected.
シェーダはバインドされ、フォーマットのコンバートが実行され、等；CPUのドライバは常時新たなメッシュを選択しています。

It is this selection process that incurs the most overhead when issuing a draw call.
この選択プロセスがドローコールが発生した際に最大のオーバーヘッドを被らせます。

However, that also means that once a mesh (or, more specifically, a vertex buffer object, or VBO) is selected, we can pay the selection cost once and draw it multiple times.
しかしながら、これは同時に一度メッシュが（あるいは、より具体的にはVBO(vertex buffer object)が）選択さえされれば、一度の選択コストで何度でも描画ができることを意味します。

As long as no new mesh (or shader, or texture) is selected, the state will be cached in the driver and subsequent draw calls will issue much more quickly.
新規のメッシュ(あるいはシェーダやテクスチャ)が選択されない限り、その状態はドライバにキャッシュされ、以降のドローコールではより手早く出力が行われるでしょう。

To leverage this behavior to improve performance, we can actually wrap multiple meshes up into a single large array of verts and draw them individually out of the same vertex buffer object.
この性能をパフォーマンス向上に発揮させるには、複数のメッシュを一つの大きなVertex配列にまとめて、同じVBO毎に描画を行うことです。

We pay the selection cost for the whole mesh once, then issue as many draw calls as we can from meshes contained within that object.
メッシュ全体には一度は選択コストがかかります。その際、オブジェクトに含まれるメッシュと同量のドローコールは発生します。

This trick, called batching, is much faster than creating a unique VBO for each mesh, and is the basis for almost all of our draw call optimization.
このバッチ(batching)と呼ばれる手法は、それぞれのメッシュ毎に独自のVBOを生成するより高速で、ほぼ全てと言っていいドローコール最適化の基盤になっています。

All of the meshes contained within a single VBO must have the same material settings for batching to work properly: the same texture, the same shader, and the same shader parameters.
単体のVBO内に収まった全てのメッシュは、バッチを厳密に働かせるため同じマテリアルの設定がされていることが必須です：同じテクスチャ、同じシェーダ、そして同じシェーダパラメータで。

To leverage batching in Unity, you actually need to go a step further: objects will only be batched properly if they have the same material object pointer.
Unityでバッチを行うには、さらに段階を踏む必要があります：同じマテリアルオブジェクトのポインタを持つオブジェクトの場合、それぞれ適宜バッチされます。

【絵】
A texture atlas
テクスチャアトラス

To that end, here are some rules of thumb:
最後に、以下のようないくつかのルールがあります：

- Macrotexture / Texture Atlases: Use as few textures as possible by mapping as many of your models as possible to a small number of large textures.
マクロテクスチャ/テクスチャアトラス：マッピングで出来る限り数を減らしたテクスチャにより、その少ない枚数の大きなテクスチャをできる限り多くのモデルで利用してください。

- Static Flag: Mark all objects that will never move as Static in the Unity Inspector.
スタティックフラグ：Unityのインスペクタで、動かさない全てのオブジェクトにStaticという設定を入れてください。

- Material Access: Be careful when accessing Renderer.material. This will duplicate the material and give you back the copy, which will opt that object out of batching consideration (as its material pointer is now unique). Use Renderer.sharedMaterial.
マテリアルアクセス："Renderer.material"にアクセスする際は注意してください。これはマテリアルを複製し、コピーを渡します。これはバッチ設定を外してしまいます。(マテリアルのポインタは単一なためです) "Renderer.sharedMaterial"を使ってください。

- Ensure batching is turned on: Make sure Static Batching and Dynamic Batching are both enabled in Player Settings (see below).
バッチONを保持する：PlayerSettingsで"Static Batching"と"Dynamic Batching"がいずれも利用可になっていることを確認してください(下部参照)。

Unity provides two different methods to batch meshes together: static batching and dynamic batching.
Unityは2つの異なる方法をそれぞれ提供しています："Static Batching"と"Dynamic Batching"です。

Static Batching
静的バッチ

When you mark a mesh as static, you are telling Unity that this object will never move, animate, or scale.
メッシュにstaticのマークをつける場合、それはUnity側にそのオブジェクトが動かない・アニメーションしない・スケールしないということを通知していることになります。

Unity uses that information to automatically batch together meshes that share materials into a single, large mesh at build time.
Unityはその情報を、マテリアルを共有するメッシュを単一で大きなメッシュへと、ビルド時に自動的にまとめるために使います。

In some cases, this can be a significant optimization; in addition to grouping meshes together to reduce draw calls, Unity also burns transformations into the vertex positions of each mesh, so that they do not need to be transformed at runtime.
場合によっては、かなり最適化できます；ドローコールを減らすためにメッシュをさらにグループ化し、Unityが各メッシュの拡縮を頂点位置として焼きこむことで、ランタイム上では変形しなくて済むようになります。

The more parts of your scene that you can mark as static, the better.
シーンの中で多くの部品をstaticに設定できればできるほど、より良くなります。

Just remember that this process requires meshes to have the same material in order to be batched.
ただ、思い出してほしいこととして、この処理はバッチのために同じマテリアルを持っていることが要求されます。

Note that since static batching generates new conglomerate meshes at build time, it may increase the final size of your application binary.
注意として、static batchingではビルド時に新規に複合メッシュを生成するため、最終的なバイナリサイズは増えるかもしれません。

This usually isn’t a problem for Gear VR developers, but if your game has a lot of individual scenes, and each scene has a lot of static mesh, the cost can add up.
これはGearVR開発者にとって一般には問題になりません。しかし、ゲームが多くの個別シーンを持つような場合、そして各シーンが多くのstaticメッシュを持つ場合、コストは追加されます。

Another option is to use StaticBatchingUtility.Combine at runtime to generate the batched mesh without bloating the size of your application (at the cost of a one-time significant CPU hit and some memory).
もう一つの選択肢は、"StaticBatchingUtility.Combine"を使い、ランタイム上からバッチを生成することで、アプリのサイズを膨らまさない方法です。(一時的にかなりCPUをたたくことと、多少のメモリがコストとなります)

Finally, be careful to ensure that the version of Unity you are using supports static batching (see “Gotchas” below).
最後に、使用中のUnityのバージョンでstatic batchingのサポートが確認できているか注意してください。

Dynamic Batching
動的バッチ

Unity can also batch meshes that are not marked as static as long as they conform to the shared material requirement.
Unityでは、shared materialの条件を満たす場合、staticにマークしなくてもメッシュをバッチすることができます。

If you have the Dynamic Batching option turned on, this process is mostly automatic.
動的バッチオプションをONにする場合、この処理はほぼ自動的に行われます。

There is some overhead to compute the meshes to be batched every frame, but it almost always yields a significant net win in terms of performance.
メッシュの計算には毎フレームで多少のオーバーヘッドが発生しますが、おおよそパフォーマンスの面で最終的に利することになります。

Other batching Issues
その他のバッチの問題

Note that there are a few other ways you can break batching.
いくつかのやり方によってバッチが壊れてしまう場合があることに注意してください。

Drawing shadows and other multi-pass shaders requires a state switch and prevents objects from batching correctly.
影やその他のマルチパスシェーダは状態の変更を求め、オブジェクトが正常にバッチされるのを妨げます。

Multi-pass shaders can also cause the mesh to be submitted multiple times, and should be treated with caution on the Gear VR.
また、マルチパスシェーダはメッシュに何度も操作を発生させることがあり、GearVRでは警告として処理されるでしょう。

Per-pixel lighting can have the same effect: using the default Diffuse shader in Unity 4, the mesh will be resubmitted for each light that touches it.
ピクセル単位ライティングも似た影響があるでしょう：Unity 4でデフォルトのDiffuse shaderを使用している場合、それぞれのライトからメッシュに光が届く毎に処理が走るでしょう。

This can quickly blow out your draw call and poly count limits.
これはドローコールを跳ね上げ、ポリゴンを上限に達させます。

If you need per-pixel lighting, try setting the total number of simultaneous lights in the Quality Settings window to one.
ピクセル単位ライティングが必要な場合、QualitySettingウインドウでライトの同時総数(total number of simultaneous lights)を1にしてみてください。

The closest light will be rendered per-pixel, and surrounding lights will be calculated using spherical harmonics.
最近傍のライトがピクセル単位で描画され、周囲のライトは球面調和関数(spherical harmonics)により算出されるでしょう。

Even better, drop all pixel lights and rely on Light Probes.
さらに良い方法は、全てのピクセルライトを外し、ライトプローブ(Light Probes)を利用することです。

Also note that batching usually doesn’t work on skinned meshes.
同時に注意点として、このバッチではスキンメッシュは処理されません。

Transparent objects must be drawn in a certain order and therefore rarely batch well.
透明オブジェクトは必ず一定の順に処理されるので、ほぼバッチされません。

The good news is that you can actually test and tune batching in the editor.
いいニュースとして、エディタ上でバッチのテストや調整ができます。

Both the Unity Profiler (Unity Pro only) and the Stats pane on the Game window can show you how many draw calls are being issued and how many are being saved by batching.
ゲームウィンドウ上のUnity Profiler(Unity Proのみ)やStats paneにより、どれぐらいドローコールが発生しているか、バッチにより抑えられているかが表示されるでしょう。

If you organize your geometry around a very small number of textures, make sure that you do not instance your materials, and mark static objects with the Static Flag, you should be well on your way to a very efficient scene.
もしごく少量のテクスチャで構成を行う場合、マテリアルがインスタンス化しないことを確認し、StaticFlagを立てた静的オブジェクトにはマークを行うことで、非常に効率的なシーンにすることができるでしょう。

Transparency, Alpha Test, and Overdraw
透明、アルファテスト、重ね描き

As discussed above, mobile chipsets are often “fill-bound,” meaning that the cost of filling pixels can be the most expensive part of the frame.
上記で検討したようにモバイルチップセットは多くが"領域塗りつぶし"、つまりピクセルを塗りつぶすことがフレームで最もコスト高い箇所になります。

The key to reducing fill cost is to try to draw every pixel on the screen only once.
塗りつぶすコストを減らすカギとなるのは、全てのスクリーン上のピクセル描画が一度になるよう試みることです。

Multi-pass shaders, per-pixel lighting effects (such as Unity’s default specular shader), and transparent objects all require multiple passes over the pixels that they touch.
マルチパスシェーダ、ピクセル単位ライティング効果(Unityのデフォルトのスペキュラシェーダのような)、そして透明オブジェクトはいずれもそれらが接したピクセルに向けて多重パスが要求されます。

If you touch too many of these pixels, you can saturate the bus.
そういったピクセルと多く接してしまうと、バスを飽和させてしまう可能性があります。

As a best practice, try to limit the Pixel Light Count in Quality Settings to one.
ベストプラクティスとしては、Quality Settingsのピクセルライト数を1に制限してみてください。

If you use more than one per-pixel light, make sure you know which geometry it is being applied to and the cost of drawing that geometry multiple times.
もし1つよりも多いピクセル単位ライトを使用する場合、適用されるジオメトリやそのジオメトリで描画されるコストは複数回になることは把握しておいてください。

Similarly, strive to keep transparent objects small.
同様に、透明オブジェクトは小さくなるよう努めてください。

The cost here is touching pixels, so the fewer pixels you touch, the faster your frame can complete.
ピクセルと接することでのコストについては、その接するピクセルが少なければ少ないほどフレームの完了はより早くなります。

Watch out for transparent particle effects like smoke that may touch many more pixels than you expect with mostly-transparent quads.
煙などの透明パーティクルエフェクトは、一般的な透明のポリゴンのそれより大量のピクセルが接触することに気をつけてください。

Also note that you should never use alpha test shaders, such as Unity’s cutout shader, on a mobile device.
同様に、モバイルデバイス上ではUnityのカットアウトシェーダのようなアルファテストシェーダを絶対に使用しないよう注意してください。

The alpha test operation (as well as clip(), or an explicit discard in the fragment shader) forces some common mobile GPUs to opt out of certain hardware fill optimizations, making it extremely slow.
アルファテスト操作(clip()も、あるいはフラグメントシェーダ内で明示的な破棄があるものも)は一部の一般的なモバイルGPUのハードウェアフィルの最適化の処理を外させ、極端に処理が遅くなります。

Discarding fragments mid-pipe also tends to cause a lot of ugly aliasing, so stick opaque geometry or alpha-to-coverage for cutouts.
フラグメント中間パイプの破棄も荒いエイリアシングを引き起こしがちで、不透明なジオメトリやカットアウトのアルファによる到達判定を詰まらせます。

Performance Throttling
パフォーマンススロットル

Before you can test the performance of your scene reliably, you need to ensure that your CPU and GPU throttling settings are set.
シーンの信頼できるパフォーマンスをテストする前に、CPU/GPUのスロットルセッティングが設定されているか確認する必要があります。

Because VR games push mobile phones to their limit, you are required to select a weighting between the CPU and GPU.
なぜならVRゲームは携帯電話の性能を限界に達させてしまうので、CPUとGPUのウェイトを選ぶ必要があります。

If your game is CPU-bound, you can downclock the GPU in order to run the CPU at full speed.
ゲームをCPU寄りにする場合、CPUをフルスピードで走らせるためにGPUをダウンクロックすることになるでしょう。。

If your app is GPU-bound you can do the reverse.
GPU寄りはその逆です。

And if you have a highly efficient app, you can downclock both and save your users a bunch of battery life to encourage longer play sessions.
そして、もし高効率のアプリができている場合、いずれもダウンクロックすることで長時間プレイ向きにバッテリー寿命をセーブすることができます。

See “Power Management” in the Mobile SDK documentation for more information about CPU and GPU throttling.
CPU/GPUスロットルの詳細については、Mobile SDKドキュメントの"Power Management"をご覧ください。

The important point here is that you must select a CPU and GPU throttle setting before you do any sort of performance testing.
ここで重要な点は、どんな種類のパフォーマンステストを行う前でも、CPU/GPUスロットルセッティングを必ず設定するべきだということです。

If you fail to initialize these values, your app will run in a significantly downclocked environment by default.
これらの初期設定に失敗している場合、初期状態では著しい低クロック環境でアプリが動作することになるでしょう。

Since most Gear VR applications tend to be bound on CPU-side driver overhead (like draw call submission), it is common to set the clock settings to favor the CPU over the GPU.
GearVRのアプリはCPU側のドライバのオーバヘッドに寄りがちなので、クロックセッティングはGPUよりCPUが優位な設定がよく行われます。

An example of how to initialize throttling targets can be found in OVRModeParams.cs, which you can copy and paste into a script that executes on game startup.
スロットルのターゲットの初期化方法の例は、"OVRModeParams.cs"で見つかります。それをゲーム開始の実行スクリプトの中にコピー&ペーストすることもできます。

Gotchas
仕様
（※超意訳：本来は「プログラム言語や環境でバグの温床や失敗の引き金になりがちな設計ミス」のことを指すジャーゴン。例：C言語での"if (a=b)"）

Here are some tricky things you should keep in the back of your mind while considering your performance profile.
性能プロファイルを検討する際に、頭に入れておくべきトリッキーな事項があります。

One particular device profile, specifically the Snapdragon-based Note 4 running Android 5, is slower than everything else; the graphics driver seems to contain a regression related to draw call submission.
１つの特徴的なデバイスプロファイル、特にSnapdragonベースのNote4でAndroid5を走らせた場合、どんなものよりも遅いです；グラフィックドライバはドローコールの呼び出しに従って退化していくようです。

Games that are already draw call bound may find that this new overhead (which can be as much as a 20% increase in draw call time) is significant enough to cause regular pipeline stalls and drop the overall frame rate.
ドローコールでの限界となったゲームでは、新たなオーバーヘッド(ドローコール回数が20%程度上昇した場合)が正規のパイプラインを失速させ全体のフレームレートを落とすかなり十分な原因になる場合があります。

We’re working hard with Samsung and Qualcomm to resolve this regression.
我々はこの状態の復帰を解決しようとSamsungとQualcommに働きかけています。

Snapdragon-based Note 4 devices running Android 4.
SnapdragonベースのNote4デバイスはAndroid4で動いています。

4, as well as Exynos-based Note 4 and S6 devices, are unaffected.
ExynosベースのNote4やS6デバイスも同様の(Android)4は影響していません。

Though throttling the CPU and GPU dramatically reduces the amount of heat generated by the phone, it is still possible for heavy-weight applications to cause the device to overheat during long play sessions.
CPU/GPUスロットルが劇的に電話の熱生成を減らしても、長時間プレイによるデバイスのオーバーヒートが発生することで、依然アプリが重くなる可能性はあります。

When this happens, the phone warns the user, then dynamically lowers the clock rate of its processors, which usually makes VR applications unusable.
これが発生した場合、電話機はユーザに警告し、プロセッサーのクロックレートは動的に落ち、通常はVRアプリケーションが利用できなくなります。

If you are working on performance testing and manage to overheat your device, let it sit without the game running for a good five minutes before testing again.
もしパフォーマンステストの仕事をしていて、オーバーヒートしたデバイスに対応する場合、再テストを行うまで5分間一切ゲームを起動させずに放置してください。

Unity 4 Free does not support static batching or the Unity Profiler.
Unity4の無料版は静的バッチとUnityプロファイラをサポートしていません。

However, Unity 5 Personal Edition does.
しかし、Unity5PersonalEditionではサポートしています。

The S6 does not support anisotropic texture filtering.
S6では異方性テクスチャフィルタリングはサポートしていません。
(異方性テクスチャフィルタリング参考：Antialiasing and Anisotropic Filtering | GeForce)

That’s all for now.
今のところ以上になります。

In the next post, we’ll discuss how to go about debugging real-world performance problems.
次回の記事では、現実世界でのパフォーマンスをどのようにデバッグしていくか議論しましょう。

For more information on optimizing your Unity mobile VR development, see “Best Practices: Mobile” in our Unity Integration guide.
UnityモバイルVR開発の最適化についてのより詳しい情報はUnity Integration guideの"Best Practices: Mobile"をご覧ください。