引自映維網 ：

Oculus最近釋出了一個關於如何優化VR體驗的新指南，其中還包括開發者在尋找和解決VR效能問題時需要注意的常見錯誤。 VR開發者執著於確保自己的Rift體驗維持在90fps以上的幀率，而他們有充分的理由需要這樣做。儘管很大程度上是因為這是提供舒適觀影體驗的最低標準（低於這一標準可能會造成使用者頭暈噁心），但如果開發者的Rift體驗無法持續維持在90fps或以上，他們的應用根本就無法在Oculus Store上發行。

為了幫助在遊戲過程中無法達到標準的應用，Oculus推出了一系列的輔助性解決方案，包括非同步時間扭曲和非同步空間扭曲。這兩者在本質上都是為了彌補當計算能力不足而出現的幀率下降。然而，這僅僅只是輔助性手段，無法解決底層的優化問題。為此，Oculus表示開發者需要投入足夠的時間來確保應用從一開始就能滿足標準。這份指南專為應用和遊戲引擎開發者設計

由於眾所周知的原因，我將這份指南人肉搬運過來，此為第一部分，雖然是Oculus家出品，但是對於其它VR平臺也有借鑑意義，尤其是Unity 和HTC VIVE。

如下，文末附中文學習筆記思維導圖：

Guidelines for VR Performance Optimization

This section covers the general principles that you should follow in order to effectively optimize your VR applications.

Overview

Optimizing VR applications can be challenging. It is easy to go down the wrong path, and end up optimizing code that doesn’t improve the overall performance of your application. Because of this, you need to identify and focus in on where the bottlenecks really are, and optimize those sections first.

VR performance issues are generally of two types: CPU issues and GPU issues. The CPU tends to be involved with manipulating the model and the camera view, and generating the scene to be rendered. The GPU tends to be involved with generating textures and shading for the meshes in your scenes. It is important to discover whether an optimization problem is due to CPU load or GPU load, and to optimize your code accordingly.

In general, you follow Amdahl’s Law for parallel programming: Optimize the sections that are utilizing the system the most. Focus on the big expensive code paths. Don’t focus on issues which, even if you reduce the costs to near zero, you would only achieve minor reductions to the overall performance costs.

It is not uncommon for one area within your application to utilize a large percentage of the system’s processing time, while the remaining areas consume much smaller percentages. You should aim to optimize the larger problem area first.

As you optimize your application, strive to change one thing at a time. Keep in mind that there can be non-trivial interactions between the changes you make, especially with complex VR applications. Ideally, try to locate in your version control software history the single change that caused the performance problem you are experiencing. Then, look for the root cause of the performance issue there. Don’t assume that multiple changes work together to cause a single performance problem.

For many people, it is easy to get a bit pedantic or obsessive about things that don’t matter in terms of bottom line performance. It is usually best to simply consider timing issues: Is the application hitting frame rate? If so, you may not need to further optimize your application, even if your code is not designed as well as would be ideal. Focus on what really counts, in terms of performance issues that impact the user experience.

Techniques for Hitting Frame Rate

With VR, every frame must be typically drawn twice, once for each eye. That typically means that every draw call is issued twice, every mesh is drawn twice, and every texture is bound twice. There is also a small amount of overhead that is required to apply distortion and TimeWarp to the final output frame (approximately 2 ms per frame). Since the Rift refreshes frames at 90 Hz, it can be challenging to hit fame rate consistently.

The following general guidelines can help you to meet frame rate::

Limit each frame to a maximum of 500-1,000 draw calls

Limit each frame to a maximum of 1-2 million triangles or vertices

Use as few textures as possible, although they can be large

Limit the time spent in script execution to 1 ~ 3 ms, for example when running Unity Update()

Systems are full of surprises, so always run a profiler to understand the way your application is using resources.

Don’t optimize too early in the development process. Simplify the code first.

Everything is relative. Compare apples to apples.

Change one thing at a time: resolution, hardware resources, image quality, etc.

Dropped frames are not worth better quality graphics.

Don’t rely on Asynchronous Space Warp (ASW) to hit rendering frame rate. ASW generates intermediate frames based on very recent head pose information, if your application begins to drop frames. It works by distorting the previous frame to match the more recent head pose. While ASW will help smooth out a few dropped frames now and then, applications must meet a consistent 90 frames per second (FPS) to qualify for the Oculus Store.

The CPU tends to be less of a bottleneck on the Rift, when compared with mobile VR devices. If you can maintain 90 Hz on a PC that meets the recommended specifications, that will broaden your reach across all hardware supported by Oculus.

Simple graphics (which are constructed out of relatively few polygons) can often provide just as good of an experience as photorealistic graphics, which typically require significantly more processing in order to render each frame.

Use techniques such as Level of Detail (LOD), culling, and batching.

Cut the shading rate by scaling eye buffers, and using Oculus octilinear rendering (which leverages NVIDIA Lens Matched Shading).

Using blob shadows.

Create your own optimized math when rendering graphical constructs.

Use cheaper projector shadows to save bandwidth.

When you are rendering to the cascaded shadow map, which can cost a lot in terms of bandwidth, consider the resolution and the number of cascades you are using. Try not to use expensive filtering. However, this approach pretty quickly ends up producing lower quality graphics. So you might use projector shadows.

Use baked shading if necessary.

Common Causes of Performance Problems

Performance problems are most commonly caused by the following issues (in order of severity):

Performance ProblemResource Costs

Scenes that require dependent renders, including shadows and reflectionsCPU, GPU

Binding of Vertex Buffer Objects (VBOs) in order to issue draw callsCPU, Graphics Driver

Transparency, multi-pass shaders, per-pixel lighting, and other effects that fill large numbers of pixelsGPU, I/O

Large texture loads, blits, and other forms of memcpyI/O, Memory Controller

Skinned animationCPU

Unity garbage collection overheadCPU