Better build times and iteration speed for Quest

Our partners on the Quest developer team wanted to understand how the latest versions of Unity affected performance and iteration speeds when building for Quest. In collaboration with Unity, they tested different Editor versions, including our LTS and Tech streams, to compare performance. Their findings were published on the Oculus Developer blog, and you can find the in-depth article in the Oculus Developer documentation.

Meanwhile, this blog post aims to highlight the Unity Editor’s improved performance and help developers on Quest reduce the time it takes to build VR experiences. Please note that these changes might require some modifications to your project.

For further details on the test project, plus data displayed in this document, take a look at the Oculus Developer documentation appendix.

With each Unity version, we’ve made incredible progress reducing build times year after year. For instance, our partners at Quest found the following during the test project:

• Upgrading from Unity 2019 -> 2020 = 33%-42% reduction in iteration time
• Upgrading from Unity 2020 -> 2021 = 8%-16% reduction in iteration time

That’s why we recommend the latest LTS for faster build times and greater stability. Learn how to upgrade to the latest LTS here.

Oculus Link lets you iterate quickly on a project. Once you connect the headset to your computer and start the scene in-Editor, you’ll get the results directly on your headset with inputs from the device. This method is useful in cases where the changes are independent from the device, like logical code changes, asset positioning, or asset updates. Situations where this is less beneficial involve iterating on a device-dependent element, like shaders and rendering, or logic specific to the device.

How to set Quest to use Oculus Link

We’ve introduced an option to patch the generated APK when developers make code-specific changes. This type of build considerably reduces the time it takes to build the changes. You can find details on how to build the patch in our App Patching documentation.

Here are some key items to consider:

• You will need to make a full build for starters.
  • Subsequent builds will be able to use the patch.
• When using IL2CPP, go to Player settings and ensure that the Strip Engine Code option is unchecked (disabled).
  • This action is for iteration purposes. You can decide how to handle it for production.

During the test project, we’ve found that projects with assets in the APK can accelerate build times by 45% as they only build code that has changed.

The Addressable Asset System separates the asset building process from the code building process. Doing this helps reduce the time spent building by solely focusing on what has changed.

Built on top of the Asset Bundles, the Addressable Asset System simplifies asset management as a whole. This system streamlines asset groupings and ensures that bundles include their dependencies.

It is also possible to have Addressables load assets remotely, which means that you can set up a local asset server on our development machine and serve the assets directly to the device. In other words, when assets are modified, you only need to build the Addressables and restart the app on the device. No deployment to the device is required.

Here is a comparison of Unity LTS 2020.1.15f1 Base project vs Addressables project:

By dividing assets from code builds, the build of the APK is more than 50% faster. When only modifying the assets, without the need to rebuild the APK, it jumps to about 75% faster.

The assets are also separated into four groups based on the shared materials, Prefabs, and meshes they used. Smaller groupings take less time to rebuild.

Another important aspect is to avoid duplicating the dependencies in multiple groups. For example, consider Scene1 and Scene2, which depend on Material1. Scene1 is in Group1 and Scene2 in Group2. If Material1 is not explicitly included in a group, it will be included in both groups. In this case, when updating Material1, Group1 and Group2 will similarly have to be updated. This can cause potential issues at runtime since we would have two instances of Material1, due to added memory or prevented batching. Material1 would be better placed in a shared group to be verified using the Addressables Analyze tool. Find more information here.

Shaders

In testing, we discovered that modifying a shader can be costly toward build time when multiple scenes use that same shader. The Addressables system will load and unload each scene that depends on the shader to check the required variants. In a project with over 1000 scenes, this results in high build times.

The bundles were thereby changed to explicitly contain the materials in those scenes, meaning we added the material to the group based on particular scenes that used them. The Addressables system doesn’t need to open each scene and stop when it looks at the material.

Note that we need to set the Addressable settings to use Non-Recursive Dependency Calculations.This can be set on the Addressable Asset Settings file, or by going to Windows > Asset Management > Addressables > Settings.

The following data reflects our discovery:

The Addressables documentation is a great resource for understanding how to set them up. Once you’ve set up the Addressables group, you might end up with both local and remote groups for the final product. It would be helpful to turn them all remote for the sake of iteration. To do this, use the Addressables profiles. You’ll create a new profile where the local groups can be built in the same location as the remote ones; the load path will also be the same as the remote load path.

Steps:

1. Set up the Addressables group.

• Set local and remote groups.

1. Change the catalog to remote.

• Set the catalog version so that it’s not using the time stamp. Once the build is made, it will always load the same catalog filename. The filename is stored in the APK. See the Catalog Settings section.

1. Create a profile for local hosting and development iteration.

• Set local groups to have the same build and load path as the remote group.

1. Build Addressables.
2. Then build Client and deploy.
3. Despite all the assets, scenes, and shader changes in Addressables, you only need to rebuild the Addressables themselves.

• Restart the app on your device to get the latest changes.
• You can set up some reload functionality on the app, but this requires the implementation of additional logic. See content updates at runtime.

If converting your current project to use Addressables is too much of a time-consuming endeavor, there’s a speedy solution. The team at Meta has developed a tool called OVR Quick Scene Preview that can divide the project into bundles and push them directly to the device.

Here you can see some data points on this tool’s capabilities when combined with Unity 2020 LTS.

Notice an improvement of over 53% in all areas except for the clean build. There is a higher time cost to make this initial build, but subsequent builds are given a considerable boost.

As we continue to make progress in terms of Editor performance and iteration time, we hope that you’ll test these improvements for yourself.

Upgrading mid-project can be complex, and the trade-offs between adopting the latest LTS and performance gains must be carefully weighed. However, with the Unity Hub, it is possible to test your project on multiple versions of Unity to see what’s involved in upgrading. For further reading, check out our blog post on accelerating Unity workflows.