This is the final article from the series about porting Unity SteamVR games to Oculus Quest. The previous articles in the series: Porting basic Unity SteamVR game's functionality to Oculus Quest Optimization techniques for porting Unity SteamVR games to Oculus Quest

Automated artifact building

You may know that it’s possible to automate artifact building in Unity. And of course, it’s possible to automate artifact building for Windows and Oculus Quest while having the same code for both platforms. We added a batch file build.bat that is used by both developers and the build-server. This script is configured with several options and will execute platform-specific code to prepare and build the project in Unity’s batch mode.

build.bat:

BuildScript.cs:

Here you can see an example with light that is baked pre-build. We use Progressive GPU Lightmapper to achieve this, and you can find the OpenCL platform and device values in the documentation. We take care of the baked light before building because we use procedural generation to slightly tweak scenes. You can remove these options if you don’t use baked lighting or if its parameters are platform-independent.

One of the most annoying things related to building both for Windows and Oculus Quest is that you have to compress textures by using ASTC for Oculus Quest. That means textures are extracted and compressed each time you switch between two platforms while building artifacts. Switching from Windows to Oculus Quest might take 2 to 5 hours depending on the number of textures. We found that the most effective way is to clone the project repo in 2 separate directories for each platform and then build them independently. Obviously, we still retain the same codebase. We replicated this approach on our build-server (Jenkins) by creating 2 different projects with separate workspaces for each platform.

Conclusion

With this article we finish our series about porting SteamVR games to Oculus Quest. Our goal was to explain our approach to having shared code and resources for both platforms to reduce development and maintenance costs. This approach is certainly not universal, but it worked for our project and might work for yours. We hope that the articles answered most of the questions you might have during the porting process and saved some of your time.