Search Unity

Yesterday, engineers from Google, Microsoft and Mozilla (makers of Chrome, Edge and Firefox) announced that they are working on a new cross-browser technology called WebAssembly. This is very exciting news, as this will greatly help improve the Unity WebGL experience.

Although it is technically defined as a new, independent standard, from our perspective, WebAssembly is essentially a bytecode format for the asm.js JavaScript subset (asm.js is used to deploy Unity code to WebGL). Compared to the currently used text-based representation, the bytecode format is significantly reducing the size footprint of code compiled to asm.js. This leads to faster downloads of code, and, more importantly, to being able to parse and compile the code much faster and using much less memory. This will improve the startup times of large compiled JavaScript codebases, and reduce their memory requirements — both of which are currently some of the more common issues developers face when targeting the WebGL platform.

We plan to switch Unity WebGL to output WebAssembly bytecode once the feature becomes available in browser releases. On browsers which don’t natively support the feature, the bytecode can very efficiently be translated to text-based asm.js code using JavaScript – which in most cases still results in faster content load times due to the download time improvements.

Experimenting with a prototype WebAssembly format on a build of our AngryBots demo, we saw the size of the generated JavaScript code go from 19.0 MB of asm.js code (gzip-compressed to 4.1 MB) down to 6.3 MB of WebAssembly code (gzip-compressed to 3.0 MB). This means that the amount of data the browser needs to process gets reduced by 3.0x, and the compressed download size gets reduced by 1.4x. Actual results may change based on the project used, but we expect to see very relevant improvements to anyone caring about WebGL deployment in Unity.

For more information on WebAssembly, see the FAQ here.

In light of this announcement, we would like to give further updates on the current status of our WebGL efforts, and on ecosystem changes we expect to happen over the next year — and on things we plan to be working on, which includes further build size improvements, SIMD.js, Shared Array Buffers (which bring threading support to JavaScript) and WebGL 2.0. So, I’d like to invite you to check out and discuss our WebGL Roadmap forum post, which has a lot of additional information.

If you are at Unite Europe in Amsterdam next week, check out my WebGL talk on Wednesday, or visit me at the hands-on labs to ask questions.

23 replies on “WebGL: WebAssembly and Feature Roadmap”

As excited as I am about WebGL, it’s just not a viable platform to export to at the moment for web playable games. I will continue to use Unity Web Player as my weapon of choice because I’ve had TONNES of issues with WebGL builds that I just don’t get when using the unity web player.

A short list of problems I experienced while building last night.

– Not all the usual post effects are supported (ambient occlusion).
– Generally slower frame rate for NO bloody reason.
– Alpha is handled HORRIBLY, almost would have to cut the use of particle effects. or fade-in tweens.
– I get an uninvited doppler effect on all my sound even when i make damn sure that doppler is disabled!
– I had to download a special media package from microsoft just so my sound files wouldnt get lost when compiling for WebGL.
– Bump sliders are ignored, if you have a normal or bump map, your only choice is to have it at FULL BUMP!

So I decided to build to Unity Web Player instead and just deal with the fact that ppl cant play the game on chrome.

I’m really looking forward to the future of WebGL, but right now I’m scratching it from my list of options.

Do you guys and gals envision a webassembly based plugin architecture? I think that could add so many possibilities. Maybe it would be neat if you could get a bunch of players using the Oculus Rift inside of a sound studio where everyone is playing an instrument. You wouldn’t need to worry if everyone has the right platform and you wouldn’t be limited to managed code. I imagine Webassembly Plugins could connect Unity3D to a vast ecosystem of webassembly code that the rest of the web has access to, and that could make Unity3D more “web like”.

Our game was exporting a file so large for WebGL, it crashed the browser while loading. Anything that can reduce file size is a huge step forward for the WebGL compiler.

That’s awesome! I hope this could improve anyway the compilation time for Unity editor too. It takes ages to produce a WebGL build nowadays…

How long will take to have WebAssemblies usable in practice, easy to work with, and effectively working at least on Chrome and Firefox ? I need this solution yesterday. I have planned and developed on last few months a complex project Unity WebPlayer based. My project looks completely unusable on the light of recent NPAPI changes. I am forced to switch to WebGL or to a similar solution in terms of 2-3 weeks.

This is great news! Well done to everyone working on this fantastic technology.

Are there any plans to support UnityAds / Everyplay in WebGL to be run within your game rather than having to run ads within the page?

Hm.. WebAssemblies as byte code.. Is it possible then even to skip JavaScript (C# -> C++ -> JavaScript) and go directly .NET -> WebAssemblies ? Should be possible with new .NET Core and Roslyn being fully open, right

That’s awesome news. It’s great that all the vendors came together (for once) to adopt this standard and decided to put developers first instead of their egos! Did’t see apple & opera listed though, but then again I’m not surprised.

The last post about NPAPI’s exit the the way forward with WebGL sounded more grim than promising. But with this new announcement, most of the issues regarding WebGL will be sorted!

Timelines? When do we get to preview this? Unity 5.2?

Does anyone know if this includes Internet Explorer? I know Edge and the other browsers are the future, but it’d be nice if IE was supported for a unified experience when developing for the browsers.

I wonder if MS is a bit in limbo with this since they’re working on Spartan. Maybe they won’t be adding new features to IE after W10 release.

microsoft is not supporting explorer and in development of Edge (formaly known as spartan), as written in the first paragraph of this article.

IE is dead. IE11 will receive security fixes for a looong time but that’s about it. All new development goes into Edge, IE is frozen for eternity.

Well this is super-exciting news! One big question : what’s the ETA? Are we looking at months or years for WebAssembly to roll out in browsers/Unity?

I love that Unity continues to adopt and implement the latest web features. Makes the life of us web devs much easier, but also forces the browser creators to continue to evolve.

As much as 3x improvement in size? That’s incredible. And the power you get from WebGL (and specifically asm) is staggering. With WebGL 2.0 in the future I’m confident we’ll continue to close the game between native vs. web performance.

Keep doing what you’re doing Unity, love it.

Comments are closed.