I haven’t had much luck loading Unity WebGL content on 32-bit OS, particularly Windows 7. I’m curious to know how many of you are also running into the same problem.
It’s important to know because according to Unity’s own hardware stats (below) the majority of Unity web based gamers are currently on 32-bit OS. If WebGL content is not loading on 32-bit OS, that’s a huge problem for us early adapters trying to push our next project on WebGL platform. We are facing a huge lose if we are unable to reach users on 32-bit OS.
Unity’s Web Player Hardware Stats 2015-14 show that 66.2% of all users who have loaded Unity Web Player in approximately the past 2 years are using 32-bit Windows OS. Leaving 33.8% on 64-bit Windows OS.
From my recent tests, I find that Unity WebGL content does not load on 32-bit Windows 7 OS on both Chrome and Firefox Web Browser.
How many of you are finding similar results?
If this is news to you, and you are interested in testing please try the Angry Bot Unity WebGL Demo on your Windows 32-bit OS and report your results. Unity WebGL Player - AngryBots WebGL Demo
@jonas-echterhoff_1 lets see what we get and depending on results, maybe we can collective figure out what bug needs to be reported and to who. As per our PM discussion you were mentioning filing a bug against Chrome, but I don’t think this issue is isolated to Chrome as I can load other WebGL content on Firefox or Chrome (on 32-bit Windows 7 OS), just not Unity WebGL content.
-If you look at our web player stats, those may or may not be representative of your intended audience. The Unity web player gets particular high usage numbers in China (by far the biggest), Russia, Brazil, Turkey, the Philipines - typically driven by popular, local content. All these countries have rather modest average hardware specs. But if you don’t plan to do localized content for those countries, then your target audience will look different.
-As for being able to load “other WebGL” content: If you look at some simple webgl samples, or, for instance three.js pieces, then you are not comparing apples to apples. Unity is very different in being a complete game engine with Physics, Audio, Animation, Text Rendering, etc subsystems, and is an order of magnitude bigger in complexity then simple 3d model viewers with some interaction. What typically breaks our use case in 32-bit OS is the memory required to parse our big JavaScript code. A more valid comparison would be this: https://www.unrealengine.com/html5/ (and indeed if you find that this does not have the same issues as our content, then, I agree, that we should investigate the differences more).
According to Micorsoft’s last Global 64-bit vs 32-bit Stats in 2010 in shows 46% on 64-bit Windows 7, and 54% on 32-bit Windows 7. While it’s been 5 years since these stats were reported, I don’t think the global market share of 32-bit systems have change drastically. It might be more likely to be in reverse by now, but that would still leave it lingering around a 50/50 share between 64-bit vs 32-bit.
One awesome thing about the Browser Platform is that you can reach a Global Audience regardless if you localize the content or not. I know because one my first successful browser games published in 2012 received 53% of it’s traffic from overseas markets with 47% in english-us markets. I never localized the game but still managed a pretty decent amount of traffic between 2012 - 2014. So I think Unity Webplayer Stats are very much relevant, and is a good starting point to gauge what we are looking at when dealing with Publishing WebGL content today.
I hope more people come on board to this Thread and provide some feedback, as loading our Unity WebGL content on 32-bit will be very important if this is our current global market stats.
OK, it seems to work! But it only works with the Angry Bot Demo on my end. When I try to run my game i get memory exception errors.
Since it seems Angry Bot Demo loads fine on latest Firefox (39)/32-bit OS, what do you think I would need to do to get my game working? As my game works great on Chrome/64-bit OS, and it’s current Memory Allocation is set to 128MB . It’s odd that I would get memory allocation errors unless Firefox (39)/32-bit OS wants even less memory allocated, what do think? I did try to increase it from 128MB to 256MB and above, still no luck, so I guess it can only take less?
@ So I guess this WebGL 32-bit loading issue is a Browser issue where we need to file bugs against both Firefox and Chrome!
At this point I can only assume that WebGL on 32-bit OS requires 64MB Memory Allocation. As my project previously had issues with Memory Allocation before on 64-bit OS but after enough optimizations I was able to lower it from 384MB down to 128MB. So the Maximum Memory Allocation allowed for WebGL content on 32-bit OS must be lower. Unless there is something else i’m missing and Angry Bot is running on 128MB or more… waiting on @ confirmation.
Regarding Building your WebGL project on Unity 32-bit Editor, no that won’t work. I saw another thread regarding this, and someone from Unity probably jonas already confirmed that WebGL will not be available on Unity 32-bit.
FWIW, AngryBots used 256MB memory. It is not all about getting that size down. The size of your code and assets probably plays a bigger role. See this Unity 5.2 documentation page for a detailed writeup: Unity - Manual: Memory Considerations when targeting WebGL
Yes i’ve been focused on lowering the heap size as I would think lower is better than more. Although I see what you mean after reading the part where is says you should increase or decrease the heap size depending if the memory error is caused by the browser or Unity. So we’ll have to set the heap size accordingly.
But!! Guess what… oddly enough as i’m ranting on about Unity WebGL not running on 32-bit OS, it’s somehow working for me now!! I lowered my heap size even lower down to 96MB today and found it loading in Chrome on Windows 7 32-bit.
Apparently Chrome was just updated today Chrome Releases: Stable Channel Update, and maybe somehow included a fix for WebGL? I don’t see anything related to WebGL in the release log. Maybe huge coincidence, but I don’t know! I know I tried lowering my heap size before to 96MB and it didn’t work before.
Interesting, and Good News! I guess that takes care of filing a bug against the browsers for this issue.
This is not a “WebGL” issue per-se. This is about memory usage of large JavaScript codebases. Whether those use the WebGL API to render or not is probably irrelevant to the problem. But I’m glad to hear it started working for you!
