Changes to the WebGL loader and templates introduced in Unity 2020.1

there is an issue with unitywebgl.loader.js and MacOS BigSur. the regex for parsing the version of MacOS errors, and the loading never finishes. I see this with Safari shipping with BigSur, didn't test Chrome or Firefox

 

Can you share for nginx?, tried the following :

Code (csharp):

1.  
2. location / {
3.             root   html;
4.             autoindex on;
5.             autoindex_localtime on;
6.             index  index.html index.htm;
7.            
8.             location ~* \.(loader.js)$ {
9.             add_header Content-Type application/javascript;
10.             }
11.            
12.             location ~* \.(wasm)$ {
13.             add_header Content-Type application/wasm;
14.             }
15.            
16.             location ~* \.(data.gz|symbols.json.gz)$ {
17.             add_header Content-Encoding gzip;
18.             add_header Content-Type application/octet-stream;
19.             }
20.             location ~* \.(wasm.gz)$ {
21.             add_header Content-Encoding gzip;
22.             add_header Content-Type application/wasm;
23.             }
24.             location ~* \.(framework.js.gz|js.gz)$ {
25.             add_header Content-Encoding gzip;
26.             add_header Content-Type application/octet-stream;
27.             }
28.         }
29.  

But getting the following from firefox :

Code (csharp):

1.  
2. The script from “http://localhost/test/Build/WebGL.framework.js.gz” was loaded even though its MIME type (“application/octet-stream”) is not a valid JavaScript MIME type.
3. wasm streaming compile failed: TypeError: Response has unsupported MIME type
4. falling back to ArrayBuffer instantiation
5.  

 

this worked
using brotli compression / chrome
Apache

 

@alexsuvorov I would really appreciate any kind of update on this.

As of right now the default settings don't work for both local builds and most servers. You can't just build your games and upload them to itch.io or any other website anymore. You have to mess with the compression settings, which seems like a really bad idea. Not to mention that it's really hard to find out what's even wrong.

The default settings for builds should just work, and as far as I see it, these settings can't stay like this moving forward.

 

Should probably have a checkbox that indicates whether one is using Apache or IIS server to automate the .htaccess generation

 

Is there any update on this issue? It has been months and even in Unity 2020.1.6 this problem still persists.
Is there an issue tracker for this?

 

Found out working nginx rules for Unity WebGL 2020.1++

Code (csharp):

1.  
2. location / {
3.             root   html;
4.             autoindex on;
5.             autoindex_localtime on;
6.             index  index.html index.htm;
7.            
8.             location ~* ^.*\.(js)$ {
9.             types {}
10.             default_type application/javascript;
11.             }
12.            
13.             location ~* ^.*\.(wasm)$ {
14.             types {}
15.             default_type application/wasm;
16.             }
17.             location ~* ^.*\.(wasm.gz)$ {
18.             gunzip on;
19.             gzip off;
20.             types {}
21.             default_type application/wasm;
22.             add_header Content-Encoding gzip;
23.             }
24.             location ~* ^.*\.(framework.js.gz|js.gz)$ {
25.             gunzip on;
26.             gzip off;
27.             types {}
28.             default_type application/javascript;
29.             add_header Content-Encoding gzip;
30.             }
31.            
32.             location ~* ^.*\.(data.gz|symbols.json.gz)$ {
33.             gunzip on;
34.             gzip off;
35.             types {}
36.             default_type application/octet-stream;
37.             add_header Content-Encoding gzip;
38.             }
39.  
40.         }
41.  

Clear the browser cache and reload the page.

 

Why is. Wasm loaded twice?

 

Hi all, I want to upgrade our project from 2019.4 to 2020 to improve the webgl loading&startup time.
Are there any noticeable improvements using 2020 instead of 2019.4?

 

I'd also like to vote on this

 

Thanks a lot for the feedback @jukka_j

 

Sure thing I can reproduce it easily. Using Unity 2020.1.9
Simply created a Universal Render Pipeline project
Changed the WebGL publish settings to use File names as hashes and Brotli as compession format.
Build settings -> Build button

The output is:
64a2dd3d1e5e18e1182aa897fbb86203.br
20648f7ddf35a283cef44385ee277c22.br
d2263bb9f51fa0474d63392695955db3.br
d18623fc4c1dbde91a5ca66c62f9e1af.js

I expected a .data.br, .js.br and wasm.br
What I got is all just .br

With the server configuration for an IIS server copied from the documentation this won't work because it is expecting the .data.br / .wasm.br / .js.br extension to be there.

Now I built one without filenames as hashes then it is simply:
.data.br
.framework.js.br
.loader.js
.wasm.br

These can be served because they have their extension as the configuration file has it set up.

 

In the interest of others who like myself may not read carefully enough at times, I'll risk restating what should have been more obvious to me (since it's pointed out clearly here: https://docs.unity3d.com/2020.1/Documentation/Manual/webgl-deploying.html). I ported a webGL project to 2020.1, and adapted web templates... all fine (though for a bit I was having strange UI/textfield scaling/display issues I didn't realize were related to the new template adjusting for Retina display by default if a player is within certain height/width bounds unless rendering is forced to a standard dpi: 'devicePixelRatio: 1'). To the main point, I started twiddling compression settings in the player and .htaccess (Apache) files to try and get Brotli properly working on my ISP, without much luck, and for far longer than I'd care to admit. Finally I realized I was testing on an unsecured (http://) server, which caused many of the errors earlier referenced in this thread. As soon as I made it secure (https://), things began working as intended, using the relevant bits from here: (https://docs.unity3d.com/2020.1/Documentation/Manual/webgl-server-configuration-code-samples.html)

 

I reported the bug, case 1287032

 

So when I build my WebGL project after updating I see things have changed a lot. I am getting a Promise error due to an Invalid or unexpected token... This is code generated by Unity that is throwing this error? Why doesn't this work by default? I would assume it would at least create the promise correctly.

The below is the error in the name.loader.js file.

Code (JavaScript):

1.     function i() {
2.         return new Promise(function(e, t) {
3.             var n = document.createElement("script");
4.             n.src = u.frameworkUrl,
5.             n.onload = function() {
6.                 delete n.onload,
7.                 e(unityFramework)  //THIS LINE IS THE UNEXPECTED TOKEN
8.             }
9.             ,
10.             document.body.appendChild(n),
11.             u.deinitializers.push(function() {
12.                 document.body.removeChild(n)
13.             })
14.         }
15.         )
16.     }

 

It appears that might be the case as the other option does run. Things have changed how you access the UnityLoader. How do you recommend I can get access to the UnityLoader.System info so I can check if the user is on a mobile device or not?

Thanks for the help!

 

Thanks so much! I am not too experience with HTML and JS so these new changes are taking me awhile to dig through. I really appreciate the help. While the changes are very different I do like how it is giving more control to the user.

 

Hi,

Brotli compression breaks the loading bars. It started in 2020.1 and is still present in the 2020.2 beta.

I wrote this up as a bug report, but I haven't had the confirmation email which I believe is automated... so I think the system has just eaten it. Not sure where you should go to report a bug report in the bug report mechanism.

This is a completely standard 3D template test project, built without compression:

https://sideque.st/asteroid/tbb

This is that same project with Brotli compression (different web server, so the brotli headers are correct):

https://killstreak.tv/tbb/

The loading bar never is in a state except for 0% and 90%, i.e. no download progress is being reported.

This isn't related to the Brotli setting in the Unity project; the same result happens if you build as compression: none and manually compress with Brotli using the correct headers.

Given all the errors in this new system, would it perhaps have been possible to roll it out as an experimental feature allowing rollback? Unity has a habit of removing or deprecating features before the new thing is ready and it makes life as a developer really crappy.

 

Have you tried it on FireFox?

 

Here's link to a workaround - https://github.com/AirConsole/xmlhttprequest-length-computable
and the thread discussing it - https://forum.unity.com/threads/webgl-progress-bar-not-updating.384375/

 

Wow, so 2020.1 and these template changes shipped with it as a known issue? That's pretty bad... if these big changes aren't going to be tested, just don't do them! The old system was OK.

The workaround seems to work, thank you!

 

@jukka_j @alexsuvorov Is there a way to access these variables (in particular LOADER_FILENAME, DATA_FILENAME and such) during a pre/post build processor editor script in Unity? I'm integrating an exported Unity webgl build into a web application bundler, and it would be nice to export those variables to a .json file for reference rather than hardcode the values manually.

I also noticed the

compatibilityCheck

function seems to have been removed, and now the checks are ran internally to the loader, with the instantiating promise being rejected returning a simple message if the browser does not support WebGL or WASM. Is there a way to run custom compatibility checks using the

SystemInfo

method on the pre-initialized unity instance like in the old loader, or is that something that we should deal with separately?

 

Thanks, I meant - can I access them in an editor script so I can do something else with them other than expanding the template files - I am not using the generated html, I have my own web-based project and would like to export those somewhere so that when calling

createUnityInstance

in my own scripts I know what to pass to the config parameters.

Yeah I guess it does, I was wondering if there was a nicer way to handle custom messages if WebGL is not present in the browser - right now the only options seems to catch the promise and check for the returned message to be either

"Your browser does not support WebAssembly"

or

"Your browser does not support WebGL."

since those seems to be hardcoded as values returned when the promise is rejected in Build.loader.js

 

One of the reasons they won't fix it is because "it's kinda hard" hahahahaha. I can't believe I read this.

 

Here is how i've temporarily fixed the issue with compressed filenames coming out with wrong name.
Hope this helps others until a fix comes out.

 

I gave two links - the first is without compression, which works. The second has Brotli, and it doesn't. You video is loading the uncompressed content, I also get a progress bar here. All testing is done in incognito, closing and reopening the window in order to ensure no content is cached. I also keep an eye on the network tab to ensure it's actually downloading something.

The issue was not present in the template system in 2019.4. The changes here caused a clear regression.

I understand it's a browser bug, but I don't care. A WebGL game with a broken loading bar is *broken*. A bug in the largest browser with a clear workaround should not cause Unity builds to be broken for two full releases, with no end in sight. There is zero chance an equivalent issue would persist on another platform. If Unity stopped working on iPod Touches for six months, you wouldn't link me to a bug on Apple's database and point the finger there. If Unity isn't going to support WebGL properly, why is it even available?

 

No, the Brotli content was hosted properly. I took a look at a 2019.4 build, and the difference between the old system and the new system is that as each file finishes loading, that file's progress is marked at 100% and UnityProgress is called with a simple ratio of how many files have loaded. In my build's case, that's three files loaded through the system, so the progress bar goes from 0%->33%->66%->90% (where decode starts if the streaming decode has not finished yet)->100%. On a connection of reasonable speed, that's enough to give a decent perception of loading.

The bug in the new template appears to be that a file completion does not mark that file's progress at 100%, and the progress bar stays at 0% until it hits 90%.

I would suggest fixing this quickly to fix the regression the new template system has caused. It's not difficult and doesn't rely on working around any browser bugs. Then the more thorny task of the Chrome workaround will be much less urgent.

As far as the rest.

1) It is not a logical fallacy that a broken load bar means a broken build. It absolutely destroys engagement. Players assume the game is broken and click away. It is a critical flaw in the product. The fact that you're willing to argue against this means you fundamentally misunderstand the value proposition of WebGL. Didn't you used to work at Mozilla, on gaming...?

2) This is a flaw immediately visible using your recommended deployment settings in the most popular browser. That nobody has reported the bug to you is not some kind of get out of jail free card. If your internal testing isn't catching this, what is it testing at all? I saw the bug on the day of release of 2020.1, and although I've submitted several bug reports for other matters in the past, I didn't bother with this because I thought it was just so obvious you either already knew about it or somebody would tell you in five minutes. That neither were true means that your internal testing is poor and few people are using the platform.

Lastly... that just wasn't a straw man. Hypothesizing your response to basic functionality being broken on other platforms is intended to convey the relative importance you place on each of them being correct. It's a valid argument to attempt, although I'm not claiming it's correct.

Obviously (to me at least) Unity cares a great deal about iOS and very little about WebGL. At least in its current form. My assumption is that you're deprecating all of this for Project Tiny when it eventually arrives... and that honestly isn't a bad idea.

I'm actually not particularly upset about the progress bar. I just consider it the straw that broke the camel's back. Basing my WebGL games on Unity was clearly a mistake, and I'm moving on. If I felt like you guys were trying hard to improve things for the future it would be one thing. But if I'm getting in to arguments with you about the importance of loading bars for web games... this isn't going to change.

In case I'm sounding too negative, like I'm just trying to beat up on you guys, Unity in general is great. I'd happily pick it again for use on other platforms, and most likely will.

 

@jukka_j ,

Is there a way to set `webglContextAttributes` on instantiate with unity 2020? Previously it was easy: https://docs.unity3d.com/2020.2/Documentation/Manual/webgl-graphics.html

I am not seeing the same option with createUnityInstance.

 

When I post my project to my server, and run from it, I get the "unityframework not found" error. Turning off "Gzip" compression (setting it to "disabled"), in the Publishing Settings WebGL tab, fixes this, but loses compression (obviously). At least it runs though.

 

Previously Unity would render the WebGL project using the height and width of the .html canvas, this was exceptionally useful. Now, the height and width is delivered to .html as {{{ WIDTH }}} and {{{ HEIGHT }}} and I've lost this important functionality of being able to set the width and height from the canvas.

Is there a way I can tell the unity instance to render the project using a height and width from my .html canvas?
Previously, I was doing this, which worked very well,

...
<style>
:root {
--myscreenWidth: 960px;
--myscreenHeight: 540px;
}
</style>

<script>
var deliverWidth = window.innerWidth;
var deliverHeight = window.innerHeight;

let root = document.documentElement;
root.style.setProperty('--myscreenWidth', deliverWidth + "px");
root.style.setProperty('--myscreenHeight', deliverHeight + "px");

UnityLoader.instantiate("unityContainer", "Build/ChessOrigins.json");
</script>
</head>
<body style='background-color:black; margin: 0px;'>
<div id="unityContainer" style="width: var(--myscreenWidth); height: var(--myscreenHeight)"></div>
</body>

 

hey i am doing a unity course of 2 weeks on unity learn for the newcomer, in tut expected version of unity is 2019, but i started making my microgame on the 2020.1.6f1 version, now in tut, it asks me to check the WebGL publisher license if it is installed or not

in 2019 i can locate it in the unity registry of the package manager
but it is not there in the 2020 package manager, so can you tell me where it is in unity 2020

 

I am SOOoooo the newbie, so apologies in advance if I'm just clueless. I just hope this saves somebody some effort:

The OP and the documentation refer to "Create a custom WebGL template by copying the contents of the
<Unity Installation>/PlaybackEngines/WebGLSupport/BuildTools/WebGLTemplates/"

I found two versions of this folder on my Mac, the index.html in the first folder works correctly, the second does not (it's not even pre-processed, just copied to my project's index.html):

1. /Applications/Unity/Hub/Editor/2020.1.12f1/PlaybackEngines/WebGLSupport/BuildTools/WebGLTemplates/Minimal/
2. /Applications/Unity/PlaybackEngines/WebGLSupport/BuildTools/WebGLTemplates/Minimal/

Here are their contents:

1. /Applications/Unity/Hub/Editor/2020.1.12f1/PlaybackEngines/WebGLSupport/BuildTools/WebGLTemplates/Minimal/index.html

Code (JavaScript):

1. <!DOCTYPE html>
2. <html lang="en-us">
3.   <head>
4.     <meta charset="utf-8">
5.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
6.     <title>Unity WebGL Player | {{{ PRODUCT_NAME }}}</title>
7.   </head>
8.   <body style="text-align: center">
9.     <canvas id="unity-canvas" style="width: {{{ WIDTH }}}px; height: {{{ HEIGHT }}}px; background: {{{ BACKGROUND_FILENAME ? 'url(\'Build/' + BACKGROUND_FILENAME.replace(/'/g, '%27') + '\') center / cover' : BACKGROUND_COLOR }}}"></canvas>
10.     <script src="Build/{{{ LOADER_FILENAME }}}"></script>
11.     <script>
12.       createUnityInstance(document.querySelector("#unity-canvas"), {
13.         dataUrl: "Build/{{{ DATA_FILENAME }}}",
14.         frameworkUrl: "Build/{{{ FRAMEWORK_FILENAME }}}",
15.         codeUrl: "Build/{{{ CODE_FILENAME }}}",
16. #if MEMORY_FILENAME
17.         memoryUrl: "Build/{{{ MEMORY_FILENAME }}}",
18. #endif
19. #if SYMBOLS_FILENAME
20.         symbolsUrl: "Build/{{{ SYMBOLS_FILENAME }}}",
21. #endif
22.         streamingAssetsUrl: "StreamingAssets",
23.         companyName: "{{{ COMPANY_NAME }}}",
24.         productName: "{{{ PRODUCT_NAME }}}",
25.         productVersion: "{{{ PRODUCT_VERSION }}}",
26.       });
27.     </script>
28.   </body>
29. </html>
30.  
31.  
32.  

2. /Applications/Unity/PlaybackEngines/WebGLSupport/BuildTools/WebGLTemplates/Minimal/index.html

Code (JavaScript):

1. <!DOCTYPE html>
2. <html lang="en-us">
3.   <head>
4.     <meta charset="utf-8">
5.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
6.     <title>Unity WebGL Player | %UNITY_WEB_NAME%</title>
7.     <script src="%UNITY_WEBGL_LOADER_URL%"></script>
8.     <script>
9.       UnityLoader.instantiate("unityContainer", "%UNITY_WEBGL_BUILD_URL%");
10.     </script>
11.   </head>
12.   <body>
13.     <div id="unityContainer" style="width: %UNITY_WIDTH%px; height: %UNITY_HEIGHT%px; margin: auto"></div>
14.   </body>
15. </html>
16.  

 

To me just trying to see if webGL is worth looking into, all this just means you made it difficult for just anyone to make even a simple webGL presentation...

Is project tiny as simple as pubishing WebGL used to be?
Is it ready for anything like that yet? Or is this going to be another ordeal like with the SRP for the next couple of years?

 

Hi there,

I apologise if this issue has already been solved BUT I'm trying to understand how to call Unity scripts functions from JavaScript since Unity have made changes to the WebGL loader post 2019.

Before the 2020.1 edition, I used to do it really simply in this way (see below)

<script>
var unityInstance = UnityLoader.instantiate("unityContainer", "Build/2Players.json", {
Module: {
onRuntimeInitialized: function onRuntimeInitialized() {

(NOW THE JS CODE)

function predictUnityClass(classIDValue) {

if (classIDValue === 0) {
window.unityInstance.SendMessage('Player', 'Stop');
} else if (classIDValue === 1) {
window.unityInstance.SendMessage('Player', 'MoveUp');
}


But now that that the webgl loader has changed I'm not quite sure where this would go