Search Unity

Unity 5.3 WebGL Updates

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 fileshere).

WebGL in Unity Cloud Buildis 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.”

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.

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!

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).

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.

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.

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.

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.

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.