Oculus has updated its UE4 Quest development tools so that developers can spend less time waiting and more time testing and iterating on their VR applications. The changes are similar in scope to recent improvements to Unity Quest development.

Because Quest is its own standalone headset, testing how an application will run on the headset itself requires packaging the application and then deploying it to the headset before being able to test it. Because this process can take a few minutes from the time you start packaging until you get to see your app in the headset, it’s very time consuming to test small changes. Iteration time—how quickly one can make changes and then see them—is a key factor in the efficient creation of any media. For developers building Quest applications, the faster the time between making changes and testing them, the more time they can spend honing their applications to be polished and perfromant.

SEE ALSO
Oculus is (still) Covering Unreal Engine Royalties for $5M in Revenue Per-game Through 2025

Oculus has introduced two changes with the goal of significantly speeding up the iteration process for developers building Quest applications with Unreal Engine 4. Some of the improvements also apply to developers building applications in their own game engine using the native Oculus Mobile SDK.

Skip APK Build When Iterating on Code

The first change allows developers to skip recompiling and repackaging their game after making code changes.

Instead of requiring the APK be rebuilt to include newer compiled binaries, a change was made to the Oculus OS to allow libraries to load automatically from the application’s dataDir instead of from the installed package if a file by the name exists, when a special flag is set in the package settings and the application is debuggable.

Oculus says the option can be found in Editor Preferences > General > Experimental, and also notes that “this option bypasses the normal Android APK build logic. If any changes are made that require a new APK to be generated, such as Java changes or Android manifest changes, you will need to disable this option temporarily to allow it to be built and installed.”

The blog post also explains how the function can be used in native development environments.

Image courtesy Oculus

Using the VR Template that comes with UE4 as a test case, Oculus says that the Skip APK Build change improved the time-to-launch by 2.95 times, from 3 and a half minutes to 66 seconds.

FASTBuild Support for UE4 Code Compilation

Oculus says it has implemented FASTBuild support, “a high performance, open-source build system […] [that] supports highly scalable compilation, caching, and network distribution.” This allows developers to speed up code compilation by distributing the work across computers on the developer’s local (or VPN) network.

The company shared instructions for using FASTBuild in its blog post, and says that the tool can speed up builds of both the UE4 editor and “any Oculus VR game projects,” which we understand to mean that it can benefit both Quest and Rift projects.

Image courtesy Oculus

For the ShowdownVR sample, using FASTBuild distributed compilation with access to 36 threads took 13 minutes and 39 seconds compared to 28 minutes and 28 seconds with local compiling on 12 threads. A fully cached build took just 3 minutes and 30 seconds. “These timings include all preprocessing, precompiled header generation, code compiling, and linking,” Oculus noted.

Newsletter graphic

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. More information.


Ben Lang
Ben is the world's most senior professional analyst solely dedicated to the XR industry, having founded Road to VR in 2011—a year before the Oculus Kickstarter sparked a resurgence that led to the modern XR landscape. He has authored more than 3,000 articles chronicling the evolution of the XR industry over more than a decade. With that unique perspective, Ben has been consistently recognized as one of the most influential voices in XR, giving keynotes and joining panel and podcast discussions at key industry events. He is a self-described "journalist and analyst, not evangelist."

  • Could be useful for very minor changes, but it sounds like they are burying it in the menus. Might be more work turning it on and off. Every time you add a new resource, it sounds like you’ll have to turn it off. It would be nice if there was a quick-build button on the main interface.

    • Remi Palandri

      There is :) In launch, there is a checkbox that you can remove.

      If you add resources it won’t require an APK change anyway as in development mode all the resources are stored in /sdcard, so this works without any change of workflow on your end. The only change you need to make is if you edit APK-related content (such as project settings or android manifest changes) that aren’t stored in c++ code.

      • Ok, sounds good. But are you certain the manifest isn’t changed when resources are added. Just the word alone suggests it keeps track of all of the resources within the package.

  • Ad

    If fastbuild is open source, you should look into how devs on other set ups like non oculus or maybe unity could use it.

  • Andrew Jakobs

    But why not just use the Link/virtual desktop for quick testing and only once in a while you actually use the native test.. That’s at least how I would do it now. Hmmm.. really must buy myself a Quest soon for testing purposes…

    • As a developer, I can say that it doesn’t always work that way. Usually you develop 90% of the application with Link/Rift, but then the final testing has to be done on the device. And if you find a bug there, you have to re-build the apk every time and this is a nuisance.

      • Andrew Jakobs

        haha, yes ofcourse the final testing has to be done on the device itself (and certainly never forget to test it during development on the device itself, that is something some people seem to forget, finish a ‘scene’, test it on the actual device, and not wait until the whole thing is ready before testing it on the actual device)..