WebGL Stuck at 90% loading...

Previously my tool can run in Webgl without any errors:

As you can see, there are messages after "UnloadTime"

Now my tool can't finish loading in Webgl, where it stucks at "UnloadTime" message:


And here is how it looks on the web:

Unresponsive message came out:


Please Help!

 

Hi, Marco.

I have recently transferred my project from an unity account to another. Then, I setup a new project collaboration with my team member (Also, I did some code changes). My team member (who is responsible for making the web build) downloaded my project and built a webgl version of the tool. When I tried to run it that happens.

It took me some time to found out that when I deep cleared cache and browsing data, the webgl tool can run again.
But the next time I load the tool again, the same error will happen...
Is this a familiar issue? I can't seem to find any solution in my search around the internet.

Memory allocated is 1025MB

(Update : consistently even after clearing cache, it can only be run in Firefox, Chrome will not run the tool)

Much thanks.

 

This is the example of the tool can't be loaded if I did not clear cache and tried to run it in Firefox

Update: The cached data cost about 50MB each time when we clear cache and load the tool again

 

Good news!

Apparently it was nothing related to the IndexedDB problem, I managed to run it after I change all the texture max size limit to lower , which is 256. (Before the duplication of my project, all the texture max size are adjusted to 256, the "not working/duplicated" version having mostly max texture limit of 2048).

Although the build file size are the same, I guessing somewhere in the WebGL takes time to compress larger size limit textures?

Hope this can help someone in the future.

Regards

 

thank you so much . it works for me

 

For me seems to be a random bug, probably something to be with memory leaks. In my case i have a lot of textures of multiple sizes and a large scene and everything works well... until i include a box with a collider inside. It's crazy

 

@Marco-Trivellato, I'm presently converting an android game to Facebook Instant game.. the problem in the loading scene, the loading stops at 90% for 30 - 35 seconds and then the unity splash screen appears.. I'm using Unity 2018.1.6f1.. is there a way to shorten this loading time??

 

Slightly similar issue, I developed a fully functional game which worked all good on ios [Safari] too. At the start I make a few calls to a server side script to validate credentials. The game loads till 90% and waits for almost 30 - 45 mins then initializing the game. So which means the game initializes all fine accept that it takes a lot of time time to initialize. Note the wait time - 30-45 is actually mins and not seconds. What could be the issue?

On Android its bliss.

 

I am still facing this issue, I am using UNITY 2019.1.1f1. I am searching for this from the long time but did not get any good luck. I have tried all the possible ways Like - Reducing the Texture, Enable Stripe Code Engine, Change Build compression type and much more. But I am still suffering with this critical issue. I will be very thankful if anyone answer this question.

 

I have the same problem.
Luckily I kept the WebGL build of the previous version (unfortunately not the project itself) by uploading the new build to a different directory on the server.

I have this issue now. Tho old version still runs fine.
The newer one has more functionality.

With the old version which runs on my computer, one user reported this problem. Later it worked for him, without any appearent reason.

My unity version is 2020-10b7.

The game that doesn't work: http://martinpi.at/games/ThermikTrainerBeta
The one that does work: http://martinpi.at/games/ThermikTrainer/WebGL
(instructions in German, I apologize. But you can see that the game starts)

 

I have the same issue with Edge, IE 11.836 doesn't display the game at all but its working ok in Chrome

 

Try disabling WebAssembly Streaming in the Project Settings/Player menu.

 

The same issues happened here.

Solution:
First, Make a Development build. [screenshot]
Then Build again. It will work.

 

I've run into the same problem when I tried to upload a zipped archive of a project I'm working on to itch.io to test a webGL build of it. (zipped with the built-in compression tool which comes with Win10, using "send to - archive" from the context menu of the build folder in Explorer). After trying out various suggestions I've read online, like disabling logging in the player settings etc, I finally found that disabling compression in the Unity project settings (player settings - publishing settings - compression format - disabled) does the trick, and allowed the project to start up. At least in my situation, as I'm uploading an archive of the build folder. I don't really have an idea why, maybe it's because I previously put gzipped .js files into another archive... And maybe there's another way without disabling compression in Unity, which I haven't found yet. So I'd be thankful for some feedback on this issue.

 

Nope, didn't work.

 

I have the same problem.
Created new project with unity 2020.1.1f1.
Changed platform to WebGL.
Added one Button to SampleScene and saved scene.
Added scene in build settings to build.

Builded project and copied to ftp - it runs, but stucks on 90% for 9 mins. Didnt run succesfully even once.

Tried development build - runs, but shows "development build" in corner. This is not acceptable for production.

 

Ok, for me the solution was:

Disabling compression in the Unity project settings (player settings - publishing settings - compression format - disabled) does the trick

 

The reason can be the new js loader, the server should be configurated for content encoded headers. You can also switch on "Decompression fallback" for gzip, or configurate your server to show it how to decompress files while loading them

Unity Documentation about it:
https://docs.unity3d.com/2020.1/Documentation/Manual/webgl-deploying.html

And about server config:
https://docs.unity3d.com/2020.1/Documentation/Manual/webgl-server-configuration-code-samples.html

 

Worked! Thx!

 

This worked for me, thank you very much.

 

This was exactly my problem and your solution worked perfectly. Thank you!

 

I'm not sure why, but even when I disable compression in player settings it still doesn't work for me.

• The version of unity I am using is 2020.1.2f1
• File is zip and includes the index.html, Build and TemplateData folder
• Build and run loads absolutely fine
• Tried it on another device
• I am trying to post my game on unity connect

 

This worked in my case:

In my case, my non-development WebGL build, built using Unity 2020.1.7f1, was getting stuck at 90% when loading in Firefox 81.0.1 (32-bit) and didn't seem to budge even after a few minutes. The scene is very small, and reaching 90% was nearly instant, indicating (from what I've read here) that the assets were very quick to load; the entire build folder is about 12MB. I tried building (again, non-development) with Project Settings -> Player -> Publishing Settings -> Compression Format set to Gzip, and again with Brotli compression, in both cases with Decompression Fallback unchecked - both these builds did not load past 90%. Building again with Gzip compression and Decompression Fallback checked seems to have solved the problem, and the game now loads fully and quickly

 

thank you

 

so same issue here - upgraded to 2020 from 2019.4.12f1 to see if i could fix issues with webgl and memory going to 5 gigs (when its around 700M tops compared to standalone(standalone being higher res sprites and all too) anyways upgraded and stuck 90% - disabled compression - and loaded into my scene - seems a bit buggy - trying to do the compression -GZIP - and decompression failback checked this time as it was unchecked previously when i had compression enabled. did not bother trying the other compression option

 

Thanks so much Bro! That worked for me as well!

 

Where can you set the max texture limit? Is this applicable for 2D games?

 

100% works with 2020.2.x.
100% still not fixed by default in 2020.2.x.

 

I have tried all of these and nothing works! I am so mad I just want to share my game with my friends! Using Unity 2020.2.1f

If I click build and run, it will open up in Edge normally, and the build file runs perfectly. If I click the Index.html file, the progress bar won't begin to move. If I put it in my github repository and use it with gitpages then it will stop at 90%, and nothing fixes it.

I want to scream, Unity is making me very angry these days

 

Do you mean locally using Windows?

 

Any new tip? I tried everything from this thread, but still stuck in 90%. (Unity 2020.2.1f1)

 

I ran into this same problem on my itch upload, but found I had been missing an important option on the itch.io uploader.
All I needed to do was check "This file will be played in the browser" on my uploaded zip.

 

We are having a very similar issue as to getting stuck at 90%

But in our case, removing compression doesn't help us.

It seems like all the files are there correctly but it doesn't seem to wanna download the .wasm file.
We presume this is because Unity Engine isn't initializing and the build isn't running.

We also assume this has something to do with our configurations on our project because if we try to load an empty scene on a new project it works fine. We tried to match all the build settings from the new project to our project but it doesn't help. Even to build out an empty scene.

We are trying on Unity 2020.3.9f1

We seem to be running out of options to try, Is there anything else we can try?

 

"What does the web browser DevTools Console tab show"
The Console tab shows no errors. It just shows the progress which comes from the Unity loader, which gets stuck at 90%

"NetworkTab"
Shows it download all the correct files, EXCEPT the .wasm.br


This issue DOESNT happen on an empty project. Only happens to our project.
Building out to 2021, doesn't give us any extra logs or information either.

 

Do the files with suffix .br have the HTTP Response header field "Content-Encoding: br" set on them?
Yes

a) Yeah, we've been trying with both s3-hosted (both compressed & uncompressed) builds as well as local (uncompressed) builds.

b) I sent you the Zipped file privately. Please let me know anything else you need.

 

Interesting that it runs fine for you.. will be curious to see if the hosted build also works.

We've found that we can only run uncompressed builds locally.. compressed builds fail due to not being able to parse the brotli files. Perhaps there's some configuration we're missing? We CAN load the compressed builds when they come from our hosted storage, though. I will DM you the s3 links for this same build (which we've tried without success).

If you are able to run those then at least that would clarify that we are doing something wrong the configurations.

 

Sorry for the confusion. To clarify - we already have the content-encoding headers set. I just meant that when we try to run any given build locally, it must be uncompressed. We cannot run compressed builds locally no matter what. This, in the grand scheme of things, isn't really a problem since we can just easily upload the compressed build to s3 to test it.

Setting the headers was the first problem we had to solve to get the builds to even download properly. Now they download without errors but the build just isn't running (and the .wasm.br file is never downloading as seen above, presumably because the build isn't running)

Were you able to run our hosted build?

 

Also, we tried these exact steps and ran into an error that I believe stems from the fact that it's failing to parse/run the .br files. This is the exact same problem that I am referring to here:

Here's the error, which we see in the browser console:

 

Thanks, that does resolve the error, but the build (this is the exact same build I sent you) still isn't running for me. There are no console errors, and all files except for the .wasm are being downloaded. Nothing happens for some reason..

Here's a screenshot of the network tab: