Unity 5.3 WebGL Updates

December 7, 2015 in Technology

The upcoming Unity 5.3 release is the fourth version of Unity to support WebGL publishing. We have made a lot of progress since we first shipped WebGL support as a Preview in Unity 5.0, so we would like to share some updates.

Changes in Unity 5.3

Unity 5.3 brings a series of improvements which are relevant to WebGL developers:

  • The Unity Standard Shader now uses Desktop-quality reflection functions for WebGL. Previously, Unity WebGL would use a simplified version of the Standard Shader built for mobile devices using the OpenGL ES 2.0 graphics library. Now WebGL uses the same reflection functions as we use on the desktop, resulting in much better quality materials.
  • Soft shadow support.
  • Unity WebGL will now handle compression for you if the server is not configured to do it. Previously, WebGL would require you to set up your web server to serve gzip-compressed versions of your files to the clients. Otherwise, you would serve uncompressed data which would mean that downloads would be several times larger than they should be. As this turned to be confusing and difficult to set up, our WebGL runtime will now automatically download gzip-compressed versions of the data if the web server is not configured correctly to serve the compressed data. It will then decompress the gzip in JavaScript on the client side – which adds a small extra delay to having the compression handled on the protocol level (which still works if your web server is configured correctly), but which means that you no longer need to read your server manual to avoid unnecessarily huge downloads. (See Distribution size here).
  • Data files will now be LZ4 compressed in memory. In WebGL, you don’t have access to a real file system. For this reason, we will keep all your assets in memory all the time. In Unity 5.3, asset data in memory is compressed using LZ4, and will only be decompressed when assets are loaded. This means that your asset data will use less space in memory, and you will be less likely to run out of memory.
  • WebGL build files can now be more easily relocated to different urls. All files generated by the build process are now referenced directly in the generated index.html file. So if you want to deploy your build data to an external hosting solution it is now easier to configure, as all the urls you need to set are handily in one place. (See Moving build output files here).
  • WebGL in Unity Cloud Build is now a platform option. Team members can directly test the game/application in the browser.
  • Improved documentation. For 5.3, we gave the WebGL documentation a makeover and added a lot of additional information. It was important for us to document, in detail, what things are currently not supported on the WebGL platform, or supported only on specific browsers.
  • Numerous bug fixes. Unity 5.3 has 28 WebGL-specific bug fixes compared to 5.2.x – and many other fixes which benefit WebGL users but are not specific to the platform. Additionally, several other WebGL-specific bug fixes have been deployed in various patch releases during the 5.2.x release cycle, which are now all being rolled into 5.3.

Making WebGL an officially supported Unity Build Target

So far, WebGL in Unity has been available as an unsupported preview technology. With Unity 5.3, we are dropping the “Preview” label and making WebGL an officially supported build target. Our Premium and Enterprise support plans will now cover support tickets for the WebGL platform.

Unity 5.3 delivers a bunch of improvements to WebGL developers as listed above. 5.2 and 5.1 have delivered similar improvements in the past. So we feel that WebGL in Unity has come a long way since we launched it in 5.0. Similarly, browser technology has improved over that timeframe. Microsoft shipped its new Edge browser in Windows 10, which supports asm.js and which runs Unity WebGL content much better the Internet Explorer 11 ever did, giving you a wider potential audience for Unity WebGL content.

So, the WebGL platform has significantly improved since we shipped the Preview in 5.0. However, this does not mean that all features of Unity will now suddenly work in WebGL, or that performance will now match native builds, or even that any content will reliably run on any browser. There are improvements in each of these areas, but they happen very gradually. Overall, however, we feel that we have a product which works well within the constraints of the platform, and we think that this is a good time to start officially supporting the WebGL build target. We have put a lot of work into our documentation to make it clearly state what limitations you are expected to run into and on what browsers.

Working with the browser vendors

Our WebGL deployment solution relies heavily on web technologies provided by the browsers. We have been working closely with all the major browser vendors over the past few years to drive incremental improvements of these technologies.

Mozilla’s Director of Platform Product Management, Martin Best said “Today marks a milestone as Unity takes the next steps to provide full support for the WebGL export target. Mozilla pioneered technologies such as asm.js, WebGL, and Emscripten that make this possible and we are energized to continue working closely with Unity and other browser makers to create the best gaming experiences on the Web.” More info on Mozilla’s blog.

At Microsoft, David Catuhe, Principal Program Manager focused on Edge and Open Web Standards commented: “WebGL and asm.js in Microsoft Edge are an important part of providing a complete web experience to Windows 10 users. By releasing its WebGL build target, Unity enables developers to deliver great gaming experiences on the Web to our users. It’s also a great opportunity for us to continue to work together on improving WebGL, asm.js and other enhancements we are bringing to the web platform.”

Google Chrome WebGL team Brandon Jones, Zhenyao Mo and Ken Russell expressed similar sentiment for the developer community, declaring: “Unity’s support for HTML5 and WebGL deployments is one of the most exciting developments in the ecosystem to date. Developers worldwide will bring their amazing content to the web using Unity’s toolchain. We look forward to continuing to improve the performance and functionality of the web platform to enable even more exciting interactive content.”

Your turn

We believe that Unity’s WebGL export is the future of gaming on the web. Join the list of Unity WebGL titles already published to the web today, such as Heroes Of Paragon, Spider Box, Big Buck Hunter.

To get started:

Comments (32)

Subscribe to comments
  1. Erica

    February 5, 2016 at 1:35 am / 

    What’s up all, here every one is sharing these know-how, therefore it’s good to
    read this blog, and I used to pay a visit this weblog every day.

    My website quickbooks company file will not open

  2. Tryk

    December 15, 2015 at 7:15 pm / 

    Any closer on WebGL for Mobile device browsers?

  3. Barney LaHaye

    December 9, 2015 at 8:03 pm / 

    WebGL much improved!, but the camera in the web build ends up pointing down. Plays fine in the editor and loads correctly in the web build but as soon as the mouse enters the frame camera points down.

  4. Vlad

    December 9, 2015 at 4:33 pm / 

    I build game for WebGL, and shwadow still pixeled, not soft, why ?

  5. bd

    December 9, 2015 at 4:52 am / 

    can you displAy interactive html content on a 3d quad?

    1. Jonas Echterhoff

      December 9, 2015 at 9:11 am / 

      No. This would be nice, but there is currently no API to render arbitrary html to a canvas (which we could then upload as a texture), or to use arbitrary html elements as a source for WebGL texture uploads.

    2. JMJ

      December 15, 2015 at 8:52 pm / 

      You can with the 3rd party library Coherent: http://coherent-labs.com/

  6. Mike Monk

    December 9, 2015 at 4:32 am / 

    4k display on unity, 125 DPI there is nothing…

  7. Meltdown

    December 9, 2015 at 2:46 am / 

    Fantastic news, WebGL is going to be a big platform for us in our upcoming release, great to hear it has come in leaps and bounds in 5.3 :-)

  8. motya

    December 9, 2015 at 12:28 am / 

    Good news!!
    I am interesting it.

  9. Luis Eduardo Nery Santos

    December 8, 2015 at 7:54 pm / 

    I Updating my Unity to 5.3. But the build modules managers are missing.

  10. Steven Bos

    December 8, 2015 at 4:00 pm / 

    Thanks Jonas for this update. WebGL is huge for us and we are absolutely excited what Unity is already bringing us today. 2016 will hopefully make haste with experimental webworkers+shared array buffers as that is the key feature that prevents us from porting our 3D GIS webapp to a (performant) WebGL app. Cheers for the Unity team with this milestone 5.3 release!

  11. Onsterion

    December 8, 2015 at 1:42 pm / 

    Great News!

  12. Vinny

    December 8, 2015 at 4:00 am / 

    What about high-level networking? Where’s the Roadmap? News?

    1. Jonas Echterhoff

      December 8, 2015 at 9:15 am / 

      If you mean Networking specific to WebGL, there’s an overview here:
      http://docs.unity3d.com/530/Documentation/Manual/webgl-networking.html

  13. Michael Chugg

    December 7, 2015 at 10:59 pm / 

    For the WebGL platform, What are the limitations of Asset bundles? Max # you can have in a project and max size of the bundles? Is there any update to the limits for these?

    1. Jonas Echterhoff

      December 8, 2015 at 9:14 am / 

      There is no platform-specific limitation. Like everywhere else you will be limited by the available memory (which can vary between devices and browsers), by how fast the AssetBundles can be downloaded (which varies between different connections).

  14. De-Panther

    December 7, 2015 at 9:03 pm / 

    “WebGL in Unity Cloud Build is now a platform option. Team members can directly test the game/application in the browser.” YYYAAAAAAAYYYY!!!! ^_^

  15. vulgerstal

    December 7, 2015 at 7:50 pm / 

    Hi.
    Can You share details on a time of day when it’s going to be released on 8 December ?
    And what timezone You’re using in Your road map, Pacific Time?
    Thanks.

    1. Jonas Echterhoff

      December 8, 2015 at 3:26 pm / 

      It is live now.

  16. DimensionU

    December 7, 2015 at 6:57 pm / 

    Does this mean that those of us who have been working to get WebGL working on ARM based Chromebooks are going to see a performance hit as compared to the 5.2.x builds?

    1. DimensionU

      December 7, 2015 at 7:00 pm / 

      Well that didn’t work. I had attempted to do a block quote cite of “The Unity Standard Shader now uses Desktop-quality reflection functions for WebGL.” but it didn’t work and I can’t edit the old message. Thus, my question is in the context of the standard shader feature.

      1. Jonas Echterhoff

        December 7, 2015 at 8:54 pm / 

        It depends. The version of the shader as it is used now does require more resources then the version used before (which was optimized for mobile OpenGLES 2.0 devices). So, if you are bound by shader fragment rate, the new shader may indeed be slower. Most likely, however, that is not your bottleneck running WebGL content a Chromebook.

  17. chingwa

    December 7, 2015 at 4:27 pm / 

    Right, and how about render texture support? This is preventing me from building my projects for webGL, and with the looming death of the Webplayer the situation is looking dire.

    1. Aras Pranckevičius

      December 7, 2015 at 7:21 pm / 

      What about render textures? They do work on WebGL just fine.

  18. Brocan

    December 7, 2015 at 4:14 pm / 

    Nice improvements! what about global illumination? any chance of using it in webgl builds?

    Thanks and great work!

    1. Jonas Echterhoff

      December 7, 2015 at 8:51 pm / 

      Baked GI works today. Realtime GI does not. The code is making heavy use of threads, so we’d either have to rewrite it to a single threaded model (and then see how bad it performs), or wait for proper threading support in JS.

      1. Sam

        December 7, 2015 at 9:38 pm / 

        So web workers don’t work for your needs and it means you’ll need something like WebAssembly to implement correctly?

        1. Jonas Echterhoff

          December 7, 2015 at 9:41 pm / 

          WebWorkers don’t allow sharing of memory like threads do, so existing multi-threaded code does not really map to WebWorkers. There is a JS draft spec called Shared Array Buffers, which aims to fix this, but currently only exists in experimental implementations.

      2. Wolfos

        December 8, 2015 at 12:54 pm / 

        Why do you guys keep saying “realtime GI”? Enlighten isn’t even close to realtime. It’s even less realtime than Beast because the bake times are much longer.

        1. Wolfos

          December 8, 2015 at 12:58 pm / 

          I mean, it still doesn’t solve the issues with procedural generation. Iteration times are still gigantic. The only improvement is that the lights can change without baking. But if you change anything else, better prepare to wait several hours.

          Actual realtime GI would solve all those issues. I understand that it’s not practical to do right now, but calling Enlighten realtime is just misrepresenting it.

        2. thom_cat_

          December 9, 2015 at 10:37 am / 

          It is pre-computed realtime GI, but it’s realtime GI nonetheless. It is the terminology they are using to clearly separate it from the baked version.

Comments are closed.