WebGL Roadmap

I wouldn't say Build Size is a major issue, as if you really have to go past 50MB even in Unity Webplayer or any other browser platform, one should consider streaming content for the best user experience.

You will lose tons of potential players if they have to wait to download 50MB or more of data. I think the general rule of thumb for browser games is limit your initial build size to 25MB or less if possible to avoid the risk of losing players at loading time. Everything else beyond 25MB should probably be streamed in (loading in the background while player begins playing the first level or going through an introduction / training).

Currently my WebGL game's build size is down to 30MB which is a huge improvement from 45MB after intense optimizations. Even my game at 30MB I don't consider this good. I have plans to make an introduction / training level that can load under 10MB or less while streaming the additional content in the background. Which can probably be done with Level Streaming https://www.assetstore.unity3d.com/en/#!/content/38368. Consider this as option to help with your game's loading issue of large build size.

 

how do you get 30mb without using gzip

 

So is that 30mb in the compressed folder or 30mb in the release folder, as I have just tested an empty scene and the compressed folder is 5.46mb and the Release folder is 26.8mb?

 

I would aim to get the compressed folder lower. Compressed folder is all you need to upload to your Web Server, no need for Release Folder. Although in order to load the compressed data from your web server you need to ensure you have mod_rewrite enabled. Here is an article on that: https://ocias.com/blog/how-to-upload-unity-webgl-content/ I'm actually surprised Unity does not point to some instructions on how to enable mod_rewrite on your web server, but guess maybe because there might not be one way to do it depending on your Web Server of Hosting Provider. Although some reference about mod_rewrite would be helpful @jonas echterhoff as I did not know what this was until I stumbled upon the link above somehow.

 

You should use gzip especially if you want faster download, and lower build size. I have no clue how you would achieve 30MB if as @Arowx just pointed out an empty scene produces 26MB Release Folder. So I'd say it's impossible unless your making a WebGL pong game or something.

 

Bring on Unity to handle compression in WebGL! Looking foward to that and all other future updates.

 

How long for 5.3 to come out

 

what's about 32x bit browsers? We was waiting update at past weekend...

 

Man, nothing works on 32 bit browsers, your demo: http://beta.unity3d.com/jonas/AngryBots/ - your demo isn't running. it's disaster!

 

In your opinion it is a disaster that a technology that is still very young and marked as experimental by Unity does not work in 32 bit browsers?

 

the transition to WebGL is tough right now especially with the pending doom of Unity Web Player on Chrome. Trust me i'm eager for WebGL to work better as well as I have two projects depending on it. We just need to be patient, it will get better! It's not all Unity's fault. If you want to shout disaster, maybe shout that towards Google for not giving us more time with NPAPI support to keep Unity Web Player running on Chrome browser. Unity is doing an amazing job! No one ever thought Unity would support WebGL for sometime! So lets be grateful they have a working solution, and even more so that it's free. (previously WebGL was suppose to be a purchased add-on)

 

maybe I'm blind.. looks on webGL demos: https://developer.mozilla.org/en-US/demos/ It's shooter and it running on a Chome 32bit with out problems( used 350Mb memory). Problems in Unity, none in WebGL
---
How many people works on WebGL from Unity command ? One, two ?

 

To be honest - there is no problem with Google disabling NPAPI - as much as I like WebPlayer I must admit that whole NPAPI architecture is old and very buggy. Sooner or later it had to be done...
But the problem is that there is no real replacement for Unity WebPlayer so far. WebGL performance (and ease of use) is still very poor comparing to WP. It is new and unstable technology that has a lot to do yet. And they disable WP without giving any alternative.
I don't mind disabling NPAPI if there could be an easy option to switch to some new technology (that could be as good or even better)... But now it's just taking away the best 3D content plugin on the web and giving nothing in exchange. That's the problem...

 

So there is no problem with Google disabling NPAPI, but they are disabling Web Player without giving any alternatives? I'm confused... it sounds like your saying it's Google's responsibility to supply a new equivalent technology to Unity Web Player. It's not their problem really, they are more concerned about security and how plugins effect the majority of their user-base which are not all gamers. Any how I don't see how we are saying anything different, the difference is your focused on Web Player being Disabeld as the main problem, but i'm saying NPAPI being disabled is the main problem. You are aware that Web Player requires NPAPI in order to function right?

 

True I see your point... BUT... can you find a Game Engine that will allow you to reproduce this WebGL demo you are referencing? or better yet any WebGL demo or game you want to make and easily export it to WebGL and any other platform you desire if you decide to change your mind? While there may be some engines available to export to WebGL like say "http://goocreate.com/" or maybe "https://playcanvas.com/" I highly doubt you will get all the same features in comparison to what Unity has to offer. But maybe you don't need what Unity has to offer and you can build your WebGL game with Goo Create or another WebGL engine. Then in that case, you don't have to wait for Unity anymore and you can probably move on to another WebGL game engine if it has the features you need to build your game. Otherwise, you'll have to be patient as Unity works through whatever challenges they face to improve WebGL on their end.

 

I agree - that's their browser and they may do whatever they want to do with it. If they find NPAPI unsafe that's OK - go ahead and shut it off.
The only problem is that - in my opinion - they are doing it too fast and there's still no Web Player alternative on the market (which of course they are not responsible for).

I understand and partially agree - but we are on Unity 3D forum and we discuss mostly game issues here (from game developers and players point of view).

You don't say

I'm not blaming Google - I just don't fully agree with them.

 

friday again)).. have any patches?

 

5.1.2f1 is out

 

Yep, they seem to have included about 5 WebGL Fixes / Updates. I'll probably Update this weekend see what improvements it has to offer my project.

• (692047) - Editor: Removed MSVCRT dependency for WebGL build.
• (none) - WebGL: Fixed an issue using System.IO.Compression.DeflateStream API.
• (none) - WebGL: Fixed error messages when refreshing or unloading the page.
• (none) - WebGL: Fixed WWW Downloads failing if they take longer then 5 seconds.
• (none) - WebGL: Prevent a runtime error due to the NetworkManager and MasterServerInterface not being correctly

 

That's Cool! I only update when I see a new full release. I hate dealing with patches.

 

5.1.2f1 has nothing useful, webGL is very gluttonous on start(taking ~2Gb memory) and still can't run in Chrome 32 bit browsers.

My code has ~50 thousand of strings, WebGL to package it all in one .js file and I was using an optimization: Strip Level = use micro mscorlib. Is webGL load all my code in memory on start?

 

How about the old doNotCaptureKeyboard?
You said many, many weeks ago that it will make it into the next patch.

Like me and many others have said: It is a critical feature.

 

I like a friday because it's a day of webGL is update =)). Please Jonas, sending webGL whitch will work on Chome 32 bit

 

Thank you so much for writing all this up. I'm sure this consumed a lot of man hours just to gather the data and document it for all of us to read.
It has been VERY helpful to me personally in understanding some of my troubles in the WebGL implementation, and saves me a lot of stress to realize some of these issues are out of my hands atm. But also gives me the confidence to keep moving forward with my projects knowing you all are working so hard to get this to work.

Thank you again.

 

5.1.2p2 is out.. no one bugs has been fixed on WebGL... ((

 

Yes, two main bugs:
1. Input field with Cyrillic on NGUI, looks two demo with same code: webGL http://dragonfly.com.ua/webGlTesting/ and UnityPlayer: http://dragonfly.com.ua/webGlTestingUP/webGlTestingUP.html
All ok in web player(android and IOS) but doesn't work in webGL.

2. Working in a 32 bit Chrome, more than 50% people use 32 Chrome (((

 

I didn't report a bug, wrote on a forum.

waiting from past New Year... needs a quality webGL platform as unityPlayer is dead, think It must be a problem number one for all Unity company

 

When a little program trying to get 1Gb++ of memory ... yep it's a problem not a Chrome
Another bug: run in background - not working on webGL (whet I go to another tab I lose control)

 

WebGL is currently known to require a lot of memory for the parsing. That's why the browser vendors are going to use WebAssembly. It is know that Chrome needs more memory for the parsing of WebGL than Firefox at the moment. So that's without doubt more a Chrome issue than a Unity bug. It is not uncommon that a build works in Firefox and crashes in Chrome.
With WebGL, you are currently very much on the edge. Sometimes it works, sometimes too many resources are needed. A lot of work needs to be done by the browser vendors and also by Unity. And I expect that might be the reason that WebGL is marked as experimental.
That should give you enough evidence that you might run into issues and shouldn't blame Untiy in a roadmap (?!) thread instead of submitting bug reports. At least create a new thread about the memory usage of Unity's WebGL in Chrome if you want it in the forum.

 

Dantus, looks, it's webGL : https://developer.mozilla.org/en-US/demos/ - all working on a 32 bit Chrome! Vendors are done all things.

And I saw WebAssembly, it's a demo with using WebAssembly : http://lukewagner.github.io/AngryBotsPacked/ I get from: https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient Demo has low size but using the SAME size of memory that why it doesn't start on 32bit Chrome

 

As mentioned, start a new thread if you want to talk about that. It definitely isn't a roadmap discussion.

 

While 32-bit Chrome is a challenge, it's not impossible. We have live Unity webgl applications where 90%+ of the users have Chrome. Our applications aren't trivial (obviously not AAA either) and only take up about ~650mb of memory. We still get a few users who receive memory crashes, but we treat them on a case by case basis (the vast majority are fine).

My only suggestion to the Unity team is prod Chrome to at least offer the 64-bit version of Chrome by default to new users (currently it defaults to the 32-bit version even when you're on 64-bit Windows). Even better if Unity can convince Chrome to automatically update 32-bit Chrome users to 64-bit Chrome if they are on 64-bit Windows. There's no real reason to run 32-bit Chrome on 64-bit Windows since plugins have been eliminated (unless if I'm missing something...?).

 

with 5.1.2p3 on 32-bit Chrome: program(empty scene) is crashed on first 20% loading(to stop load and get more and more memory after 800Mb is crashing)

 

I wonder if it's a browser limitation as you are limited to 4gb in a 32 bit address space. I'm guessing that the game/app and browser are allocating a chunk of memory to work within and if this goes over a limit it will fail?

Does it vary between browser types?

 

I'll just leave this here.

http://www.gamedev.net/page/resourc...y-nasa-switched-from-unity-to-blend4web-r4150

 

Compared to Unity, Blend4Web is a lightweight 3D engine, with a limited feature set. However there a numerous scenarios (like nasa) thinkable where a lightweight 3D engine is sufficient and even preferable to a fully featured engine like Unity.
It would be nice if UT comes up with a solution that enables stripping large parts of the engine when exporting to WebGL. I agree waiting for future technology from 3rd party developers isn't a solution.

 

I agree, Unity's WebGL and Blend4Web are completely different. Blend4Web was designed around WebGL, while Unity needs to bring all its functionality into the WebGL world. At the moment, WebGL is very sensitive for such huge code bases as Unity (especially Chrome at the moment). The technology is very young and solutions built around WebGL are going to have an advantage up to a certain point.
As far as I know, stripping already works quite well in WebGL. If you don't use PhysX, it won't be in the build, if you don't use Box2D, it is not going to be included, just like the Unity UI and other parts. It also works for your own code.


Some comments about the article:
The author also didn't carefully research the whole topic it seems. It is mentioned that movie textures and networking don't work, but Unity already offers solutions to those in the Asset Store:
Movie Textures: https://www.assetstore.unity3d.com/en/#!/content/38369
Networking: https://www.assetstore.unity3d.com/en/#!/content/38367

The section that Unity is waiting for new technology contains a lot of wrong information. The author somehow makes a conclusion that Unity isn't actively improving WebGL and they are just waiting for improvements being made by browser vendors. This is simply wrong. It only takes a few minutes to find out that WebGL is frequently mentioned in recent release notes. And it is also very simple to understand that many il2cpp improvement will also help WebGL.
As Unity is heavily using SIMD and multi threading, they are certainly awaiting the arrival of those in browsers as this will help to improve the performance a lot! WebAssembly will help to reduce the memory usage as the parsing will be heavily improved with it. With a huge code base, that certainly makes a difference. And again, they are not just waiting, they are also reducing the size of the generate code!

Blend4Web is amazing and it was designed around WebGL and as such they had a lot of flexibility to create it while Unity is a whole game engine that needed to be ported to WebGL. As WebGL is still very new, it is not surprising that a solution that was specifically created for it works better at the moment.

 

Can someone knowledgeable enough please describe the process of how the current browsers are going to incorporate Web Assembly and cut through the red tape?

 

Thanks for that explanation, Jonas! I wanted to know more what needs to happen for the key browsers to support this new format. You know, bueracracy and stuff of sort, after the 'big dream' is in place.