@Shehzan_Mohammed As promised on our meeting, I will describe here our experience with trying to enable Cesium for WebGL.
We use a customized version of the Cesium 1.20 package to create the WebGL build on our CI server. We have applied that change to make it possible to build with WebGL target from our Linux server.
As a first step, we enabled C++ Multithreading support for WebGL in the Unity project, as the WebGL build fails otherwise.
Next, we configured our server to use the needed COEP / CORP / COOP headers to make C++ multithreading possible. This was not enough, as we were including some external javascript in our index page, and these were failing to load because of the COEP. This was solved by adding the crossorigin="anonymous" attribute within the script tag.
But our app still fails to load. More specifically, it tries to load the url https://ourserver.com/undefined, but fails. That is a resource that was not being fetched before these changes, and we are still trying to figure out why that happens. From that ‘undefined’, it seems that the url was formed from an undefined javascript variable.
I will update here further if I have more information.
More specifically, it tries to load the url https://ourserver.com/undefined, but fails.
I have found why that happens. That was actually the fetch of the worker javascript file.
We use a customized index.html. We had to add the following line in there:
var config = {
...
#if USE_THREADS
workerUrl: buildUrl + "/{{{ WORKER_FILENAME }}}" + cachehash,
#endif
That problem probably won’t occur for someone that uses Unity’s default index.html page.
Another problem was that a third party javascript library would fail loading: it tries to access the window object, which is undefined. It seems that the worker.js file loads that script too, where there is no window context. This was fixed by adding the following line to jslib before any window access occurs:
if (!ENVIRONMENT_IS_WEB)
return;
We are not done yet. This time our app loads further, but we get a stack overflow somewhere. To be investigated further.
Please note that all this happens before any Cesium is executed at all. These problems are a consequence of enabling multithreaded C++ support in our app.
I’m curious about the server setup challenges you’re facing for the multithreaded Wasm. It’s unfortunate the server requirements is such a pain, due to the past Meltdown and Spectre exploits that plagued browsers. If you could send me a postmortem of what you’ve had to go through, I can share it with the Unity web team so hopefully it could help guide documentation to help guide others.
Hi Brendan.
I had to put this task aside for some time because of priorities. I still have to debug why our app fails to start when we enable multithreaded C++ (it actually hangs somewhere at our loading screen. The loading animation keeps running). My impression is that it is not about COEP now, but some interaction of multithreaded C++ support with our app’s code flow. Please note that we don’t do explicit use of multithreading or Jobs system.
It wasn’t a stack overflow, as I initially thought. Chrome Developer Tools misled me by showing what looked like endless recursive calls from the rendering loop, but it turns out it was simply showing scheduled tasks in the trace (such as scheduler → scheduled task).
I should debug this hang further, maybe through a debug-enabled WebGL build. But we are close to function count limits even on our release build, and it is hard to iterate on WebGL builds locally (because it takes hours to build). I will see what I can do.
Ok, I think I came closer.
It seems that I have overlooked that some Auth0 script still had some cross origin error, such that authentication did not work. It was a request like this that was failing: appserver/index.html → cdn/auth0.js → externalAuthServer/authorize. I got that working temporarily.
The following issues were related to the fact that enabling native C++ multithreading automatically enabled some other flags:
- Option ‘Enable BigInt’
We were getting the following error in the console:
Uncaught exception from main loop:
Uncaught TypeError: Cannot convert 4278190080 to a BigInt
Solution: return BigInt(number) instead of number from a .jslib function.
- Option ‘Use WebAssebly.Table’
We were getting such an error in the console:
Invoking error handler due toTypeError: Module.dynCall_vi is not a function
at instance.ws.onopen (WebGL.framework.js.gz…)
Solution: replace Module.dynCall_* with {{{ makeDynCall(....) }}} in .jslib files. See Unity - Manual: Replace deprecated browser interaction code.
This time our app itself works ok. When I enable a tileset, I see that root.json file is requested repeatedly from the google server. But I don’t see any tiles on screen.
This is printed repeatedly on the web console:
WebGL.framework.js.g…3f6aa0b5f189a94b:14 The referenced script (Unknown) on this Behaviour is missing!
WebGL.framework.js.g…3f6aa0b5f189a94b:14 The referenced script on this Behaviour (Game Object ‘CesiumCreditSystem’) is missing!