sebjf
commented
1 year ago TLDR: call UnityUtil.useUnity2023() in viewer.tsx setupInstance (right after UnityUtil.init), masked by whatever condition we want to switch between them. Not doing anything will get the default viewer.
Swapping between the viewers is now supported through the introduction of a new variable unityBuildSubdirectory.
The Unity viewer is loaded by assembling a set of URLs like so:
[Domain Hosting Unity]/[Build Subdirectory]/[Hardcoded Resources]
For example, both our viewer and white-label viewers resolve unity.loader.js like so,
[3drepo.io]/[unity/Build]/[unity.loader.js]
This is then used to initialise a script element which then calls UnityUtil.loadUnity(). Inside loadUnity further resources are resolved like so,
const buildUrl = new URL(UnityUtil.unityBuildSubdirectory, UnityUtil.unityDomain);
dataUrl: `${buildUrl}/unity.data.unityweb`,
frameworkUrl: `${buildUrl}/unity.framework.js.unityweb`,
codeUrl: `${buildUrl}/unity.wasm.unityweb`,Additionally, the indexedDbCache worker expects to find indexeddbworker.js inside [Domain]/unity/indexeddbworker.js.
To support 2023 as an option, the 2023 Unity project should build into frontend/unity/2023/unity.
- Making the directory a subdirectory of
frontend/unity/causes all dependencies to be copied by Webpack, without needing to modify the webpack configs for this limited-time feaure. - The subdirectory ends with
/unity, because the name of the build folder also defines the start of the filenames of the aforementioned resources - so to keep the loading code identical, all builds have to build into a folder calledunity, no matter where this folder sits.
Additionally, the viewer.tsx is modified to get the loader script address from UnityUtil via a function call, instead of setting it itself. This address is based on unityBuildSubdirectory.
So, when the 2023 viewer should be used, the unityBuildSubdirectory should be changed from its default of /unity/Build to /unity/2023/unity/Build.
This can be done by calling the UnityUtil.useUnity2023() method.
- If this is not called, the
unityBuildSubdirectorydefaults to/unity/Buildin UnityUtil.init(), which is called before the viewer resolves the loader script address. - White-label viewers initialise the loader script address as a hardcoded path under 3drepo.io. Since the build directory for the default viewer has not changed, this will still work without any changes.
- The indexeddbworker has not changed between unity versions, and is stored above
Build(webpack writes it into[Domain]/unity/, so this also does not depend onunityBuildSubdirectoryand will continue to work without changes.
Description
New versions of Unity support more recent versions of emscripten, which support for 4GB address space (1.39+).
We would like to allow specific customers to get access to a version of the viewer built with 2023 and the enhanced memory.
The new version of Unity does not change how the viewer is loaded. There is a minor change to how API calls are chunked, which has been added to support loading the models the 2023 upgrade has been tested for. (It is quite likely this would be required for those same models on the older version of the viewer too.)
This issue is to (1) properly implement the new chunking behaviour and (2) provide support for switching between viewers in
UnityUtil.Goals
multipleCallInChunksoperates in smaller chunks (5000) and distributes calls over sequential unity frames (allowing the gc to run between them)https://docs.unity3d.com/2023.2/Documentation/Manual/webgl-native-plugins-with-emscripten.html