Closed carmenfan closed 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
.
frontend/unity/
causes all dependencies to be copied by Webpack, without needing to modify the webpack configs for this limited-time feaure./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 called unity
, 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.
unityBuildSubdirectory
defaults to /unity/Build
in UnityUtil.init(), which is called before the viewer resolves the loader script address.Build
(webpack writes it into [Domain]/unity/
, so this also does not depend on unityBuildSubdirectory
and will continue to work without changes.@carmenfan This should be ready for someone to add the flag to the viewer settings.
This flag should cause viewer.tsx
to call UnityUtil.useUnity2023
just after UnityUtil.init
(otherwise it doesn't need to do anything).
I have pushed both versions of the viewer, but have not rerun azp, so as soon as this is run after the flag is added it should work!
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
multipleCallInChunks
operates 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