How to effectively improve the performance of Unity Gear VR game _VR

Absrtact: OK, so you decided to use Unity to do a VR game and selected the Samsung Gear VR as your target platform. After doing well, open the application, on the device to execute the file easily but – But there is a problem, the frame rate is too low.

OK, so you decided to use Unity to do a VR game and selected the Samsung Gear VR as your target platform. After doing well, opening the application and executing the file on the device is easy-but there is a problem, the frame rate is too low. A blinking black edge appeared on the horizon, feeling as if someone had kicked the camera operator's belly. You've heard of how important it is to maintain a stable frame rate, and now you understand why – in virtual reality, anything less than 60 frames per second doesn't look good, and it's the worst that makes people miserable. Your high-end upper-profile desktop can run the game up to 1000 frames per second, but the chassis sounds like an airplane engine, and ... The fan-launching time box seems to have really risen a little. Now all you have to do is optimize your work for the mobile chip. This series of articles is aimed at this problem. Part One: Some characteristics of operating environment and high efficiency VR application

This is not an optimization encyclopedia for Gear VR, it's more like a quick primer. In this first post we will discuss the hardware of the Gear VR and some features of a well-designed mobile VR application. You will then focus on how to improve your performance against your application. This article is focused on Unity because it is currently the mainstream engine of Gear VR development. However, these concepts are also applicable to other engines. Get to know your hardware

Before you dump eight pieces of your project to find inefficiencies, it's a good idea to take a moment to think about some of the performance features of mobile phones. Overall, the mobile graphics pipeline is based on a very fast CPU, with a slow bus and/or content controller to connect to a fast GPU, and an OpenGL ES drive that costs a lot. Gear VR runs on the Samsung Note4 and S6. These two product lines represent several different hardware specifications: The core of note 4 has two types. The version sold in North America and Europe is based on Qualcomm's Xiao (SnapDragon 805), while in South Korea and some other parts of Asia, Samsung's own Orion Chip (Exynos 5433) is essentially the same. The Xiao Chip is a quad-core CPU specification, and Orion has eight cores, which correspond to two Gpu:adreno 420 and mali-t760 respectively. Note 4 is also divided into two systems by the nearest Google. Respectively, are Android 4.4.4 (KitKat) and 5 (lollipop). Now basically the world's Orion's Note4 are running Android 5.0 (it seems I'm dragging the world down). S6 has only one core: Exynos 7420 (the graphics chip is MALI-T760M8). There's another version of S6,s6edge, but they're all the same except for the different shapes. All the S6 are Android 5.0 Lollipop systems.

It looks so complicated, doesn't it? OK, all of them are really close to performance and performance (except in one condition, the bottom note), if you can run well on a device, there should be no life problems on the other.

Like most mobile chips, the properties of their 3D graphics performance are relatively stable and reliable. So here are some common causes for your project to run poorly (in order of severity): The scene requires a separate renderer (such as Shadow and reflection) (Cpu/gpu overhead) to bind VBO to draw calls (cpu/drive overhead) transparent, multi-channel rendering, Per-pixel lighting and other pixel effects (gpu/io overhead) Large texture loading, blits, and various types of memory overhead (io/memory control Overhead) skin animation (CPU overhead) Unity garbage collection overhead (CPU overhead)

On the other hand, these devices have a relatively large memory, can be painted more polygons. Note4 and S6 both have 2560x1440 resolutions, but by default we generally only render 1024x1024 texture resolution to save the fill rate. Learn about your VR environment

VR rendering is the most rigorous test of hardware performance, since each frame must be drawn to the eyes two times. In Unity 4.6.4p3 and 5.0.1P1, it means that each drawing call is executed two times, each grid is plotted two times, and each texture is bound two times. In addition, a small amount of overhead is assigned to the final distortion and time travel (2ms budget). Although we look forward to the future hardware performance and the process of the process will be better, but now is to have to draw two times per frame. This means that the cost of VR games is almost one times more than the average game.

Based on these features, the following are some of the more reliable Gear VR application rendering targets.

This frame has about 30,000 polygons and 40 drawing calls

Each frame 50–100 a drawing call per frame 50k–100k the less the polygon texture map the better (but each can be very large) script execution time within 1 ~ 3 milliseconds (Unity Update ())

Note that these are not rigid norms, but our experience.

Note also that the Oculus Mobile SDK introduces an API for CPU and GPU throttling reduction to control heat and battery consumption (refer to the use of sample OVRModeParams.cs) so that you can choose to control the CPU and GPU overhead in a scenario. For example, if there is a problem with the submission of the drawing call, you may be able to increase the overall frame rate by allowing the CPU to rise (and also to reduce the GPU frequency). If you ignore these practices, your application may be forced to run in a frequency-reducing environment, so you'd better spend more time on it.

Finally, the Gear VR also has Oculus asynchronous time traversing (asynchronous TimeWarp) technology. TimeWarp can get the next frame image based on the recent head posture information as the program slows down. It distorts the previous frame by using the head information to help you have a smooth experience even if you occasionally lose a few frames, but it's definitely not an excuse to run your application at 60 frames per second at random. If you can see the black color block when you sway your head around, it means your game has slowed to TimeWarp there is not enough frame to fill up the black space. Designed to perform performance

A good application is designed to perform well, which means designing your art resources around the features of the mobile GPU. Preparation matters

Before you start, make sure your Unity project is set up for the highest performance. In particular, it is determined that the following values are set: Static batch (batching) dynamic batch (dynamically batching) GPU skinning (GPU skinning) multithreaded rendering (multithreaded Rendering) Default direction to the left of the horizon (default orientation to Landscape) batch

What we now know is that, generally speaking, the number of draw calls is the most resource-intensive aspect of Gear VR applications, so the first step in optimization is to make some design on the art level, so that the fewer drawing commands are invoked when the program is finally implemented. A drawing call is a command on the GPU to draw a grid or part of the grid. The most resource-intensive part of this command is actually the grid's choice itself. Every time the program decides to draw a new grid, the grid must be driven for processing before being presented to the GPU. The shader must be bounced back, some format transformations can occur, and so on, and these processes will occur every time a new grid is selected and occupy the most overhead.

But it also means that each time a grid (or, more specifically, a vertex buffer object Vbo) is selected, it can be used multiple times only if it takes up this overhead. As long as no new grids (or textures, shaders) are selected, the current state persists in the driver cache and can be reused. To take advantage of this feature, we can integrate multiple meshes into a large vertex array and draw separately through VBO. Once we pay the price of a choice, we can call from multiple grids contained within this object without increasing the overhead of the system. This approach, called batch processing (batching), is much faster than creating VBO for each of the different grids, and is also the basis for optimizing the drawing calls.

All grids in a single VBO must have the same material to perform batch consolidation: the same textures, shaders, and shader parameters. To be more efficient at using batches in Unity, we have to go further: objects must have the same texture object pointers. For this reason, here are some reference rules:

Texture Set/Map

Texture collection (Macrotexture/texture atlases): achieves as few textures as possible by mapping as many models as possible to a few large texture collections. Static flag (Static Flag): All objects that are not moved are marked as static in Unity Inspector. Material access: Careful access to renderer.material. This operation copies the material and returns it to you, causing the object to be excluded from the batch (because the material pointer becomes unique). Please use renderer.sharedmaterial. Make sure the batch is open: Ensure that both static and dynamic batches are turned on in player settings (see below).

Unity offers two ways of batching the grid: Static batch processing and dynamic batching. static batch Processing

Once you mark a grid as static, it means you tell Unity that the object will never move, deform, or scale. Unity will automatically integrate all the meshes of the same material into a large one, based on this point. In some cases, this will be a good optimization, not only reduce the number of drawing calls, Unity also turned the deformation operation into the location of the vertex selection, so that the operation does not need to deform. In a scene, the more parts can be labeled as static, the better. Remember that only the same material can be integrated together oh.

However, it is important to note that static batches generate a new large grid, which may result in a large application capacity. In general, the problem with Gear VR developers is small, but if you have many different scenarios in your application, each with a lot of static grids, then the final occupancy may be quite large. So another option is to use Staticbatchingutility.combine at run time to generate batch grids without making your application too big (but you have to pay a one-time CPU overhead and a certain amount of memory footprint).

Finally, be careful with your Unity version to confirm that you support static batching (see the final note). Dynamic Batch Processing

As long as the same material is shared, Unity can also batch the grids that are not marked as static. As long as you open the Dynamic batch processing options, the rest of the basic is not too much control. Batch processing for each frame can have some overhead for computational performance, but generally there is always a boost to overall performance. Other issues in batch processing

Of course, there are other things to be careful about. For example, to draw shadows on objects, other multi-channel shaders (Multi-Pass shader) that need to be converted to objects will have problems with the batch. Multi-channel shading will allow the grid to be submitted multiple times, and must be handled carefully for Gear VR. The Per-pixel lighting also has a similar effect: using Unity4 's default diffusion shader (diffuse Shader), the grid is resubmitted every time the light touches, and will soon consume your drawing calls and polygons. If you need to light pixels by pixel, you can try setting the total number of concurrent lighting in the Quality Settings window to one. The most recent rays are rendered in pixels, and the surrounding light is computed by a spherical harmonic function (spherical harmonics). A better way to do this is to give up pixel-by-line illumination, using light probes. Also note that the batch process does not support the skin grid. Transparent objects must be drawn in some order, so it is difficult to get the proper batch processing.

However, you can still test and adjust the batch processing in the editor. Whether it is in unity Profiler (Unity Pro only) or the game window of the statistics column, can show how many drawing calls are currently released, how many are saved by batch processing. If you organize your geometry around a small number of textures, make sure you don't instantiate your material and label static objects as static flags, so the whole scene is generally more energy-efficient and greener. Transparent, Alpha Test, and repeat drawing (overdraw)

As mentioned above, mobile chips are generally "filling rate bottlenecks", meaning that pixel padding may be the most expensive place in a frame. The key to reducing the padding overhead is to try to make each pixel only one time. Multi-channel shaders, pixel-by-color lighting effects (such as the Unity of the default high-light shader), as well as transparent objects such as the need for more than one pixel rendering. Too much, it will affect the bus.

As one of the best practices, you can try limiting the number of pixels (Pixel Light count) to one in the quality setting (Quality settings). If you exceed one, make sure you know what part of the problem is and what the overhead is. Also, try to make a transparent object smaller. The overhead is determined by the pixels you encounter, so the less pixels you touch, the faster the frame will render. Beware of transparent particle effects, such as smoke, and the number of pixels involved may exceed your expectations.

Also note that you should not use alpha test shaders on mobile devices, such as Unity's Hollow shader (cutout Shader). The operation of Alpha Test (and clip (), or explicit discard in the fragment shader) forces the current majority of mobile GPU to undo those hardware optimizations, making it extremely slow to run. Discarding fragments in the pipeline often results in ugly anti-aliasing, so use opaque geometry or Alpha to coverage for hollowing out. Performance throttling

Before you can reliably test your scenario, you need to ensure that the CPU and GPU throttling settings are set. Because VR games have squeezed the performance of the handset to the extreme, you need to have a good grasp of the balance between the CPU and the GPU. If your game bottleneck is on the CPU, then you can reduce the frequency of the GPU to allow the CPU to run at full speed. If your application bottleneck is on the GPU then you're in the opposite. If your application is highly efficient, you can reduce the power consumption and temperature by reducing the CPU and GPU. The section "Power Management" in the CPU and GPU mobile SDK documentation is available to read more about the CPU and GPU throttling settings.

One of the more important places is to select a throttling configuration for the CPU and GPU before doing this kind of performance test. If these specific values are not initialized successfully, your application will be run by default in a frequency-reducing environment. Since most Gear VR applications are limited by the drive overhead (such as the number of rendering calls submitted) on the CPU, it is generally more advantageous to set the frequency for the CPU. You can find an example of how to initialize a throttling target in OVRModeParams.cs, or you can copy and paste it directly into a script that executes at the beginning of the game to test the effect. Attention matters

These days you should be aware of the performance of your application: running under Lolipop Xiao 805 core Note4 is slower than all other versions of Note4; Seemingly graphics-driven this piece has regressed. If some games in the drawing call this piece is already in the end then it is possible to discover new bottlenecks (up to 20% more response time), enough to allow the regular pipeline to pause and cause the frame rate to drop. We are trying to solve this problem in common with Samsung and Qualcomm. The Xiao Dragon 805 Note4, which runs Android 4.4, and Orion Note4 and S6 equipment are unaffected by this. While reducing throttling for the CPU and the GPU can greatly reduce the heat of the phone, those expensive applications can still overheat the phone during a long period of use. When this happens, the phone emits a warning and then dynamically lowers the processor's frequency, which generally results in a low application frame rate. If you run into this situation when performing a performance test, turn off the application and let the phone rest for at least five minutes before continuing the test. Unity 4 Free version does not support static batch processing as well as Unity Profiler. But the Unity 5-person Edition supports these. S6 does not support anisotropic texture filtering.

This is basically so much now. In the next post, we'll talk about how to make mistakes in the real world with reduced performance problems.

For more information on optimization in Unity Mobile VR application Development, check out the "Best Practice Guide: Moving Side" section of our Unity Integration Guide.

Via:oculus translation Source: Vrerse code