Replicate functionality of "split application binary" for OBBs > 2.0GB

When building our app (for Oculus Quest) using the split application binary option, Unity produces a .apk file around ~45 MB and a much larger .obb file. Depending on the number of scenes included in the build, the .obb file size will increase above 2.0 GB, which means the build will fail.

In our optimal scenario, we would just be able to increase this size limit and our problem would be solved (the Oculus store, where we are shipping the project, allows .obb files up to 4GB). However, realizing that this isn't possible, we are trying to replicate the functionality of the "split application binary" function using AssetBundles.

Unfortunately, our first attempts at this, in which we included only some scenes in the asset bundle, have resulted in some seriously strange performance issues. Upon loading in a scene kept in the asset bundle, the framerate tanks from 72FPS to ~20 FPS, and we are seeing numerous flickering graphical glitches.

I'm at a bit of a loss trying to figure out exactly what is causing these glitches - the device doesn't report unusual GPU or CPU utilization numbers, nor does the Unity profiler when attaching to the device.

In another attempt to solve the issue, we put every scene other than the first scene into the asset bundle, akin to what the "split application binary" option does. However right off the bat this doesn't seem to match the built-in option, since the resulting .apk is ~800 MB vs the ~45 MB. Additionally, it causes more errors as the game seems not to be able to find script assets needed to create objects in subsequently loaded scenes.

Any ideas what could be happening here and how to most closely replicate the built-in functionality while bypassing the 2GB limit? Any help would be much appreciated!

 

Hi @thebarryman I was wondering what you ended up doing to solve your issue?

 

@icormier Unfortunately I had forgotten that we even had this problem until you replied to the thread! One thing I do remember that we solved was an issue relating to asset duplication. If a scene in an asset bundle needed a shader that was also used in the main app binary, then it would create a duplicate version of the shader rather than using the one that had already been loaded. The way we got around that problem was to put all shaders, textures and materials into their own dedicated bundle that was loaded on initialization. Again not sure this is what fixed it but I do remember that fixed one of our issues relating to bundling.