Search Unity

昨日、Chrome, Edge と Firefox の開発会社である GoogleMicrosoft および Mozilla が、WebAssemblyという新しいクロスブラウザテクノロジーについて発表しました。これはとてもエキサイティングなニュースで、なぜならUnityのWebGL向け機能におけるユーザー体験を大きく向上させるものだからです。

WebAssemblyは技術的には新しい、独立した標準として定義されていますが、私たちから見ればこれは要するに asm.js という JavaScript サブセットのバイトコード版と言えます。(asm.jsはUnityのコードをWebGLで動作させるために使用されています)現在のテキストベースの表現と比較すると、バイトコードを使用できることでサイズを圧倒的に小さくすることができます。これはコードをダウンロードする速度を改善するだけでなく、JavaScript上でのコードのコンパイルもより速く、少ないメモリで出来るようになることを意味します。コードのコンパイル速度およびメモリ使用量は、現在UnityのWebGL機能を利用している開発者には、いくつかあるよく知られた問題の一つです。
私たちは、ブラウザがサポートをし次第、UnityのWebGL出力をWebAssemblyバイトコードに切り替える予定です。この機能をネイティブでサポートしないブラウザについては、バイトコードはJavaScriptを使ってブラウザ上で大変効率よくテキストベースのasm.jsに変換出来るため、そのような対応にする予定です。 – その場合でも、ダウンロードサイズが小さくなることで、最終的にコンテンツをロードするまでの時間はほとんどのケースで改善するでしょう。

私たちがWebAssemblyフォーマットを実験してみたところ、AngryBotsを使ったデモではasm.jsを使ったケースでは、生成されたコードは19.0MB ( gzipに圧縮後は4.1MB ) であったのに対し、WebAssembly バイトコードでは6.3MB ( gzip圧縮後は3.0MB ) まで小さくなりました。これはどう言うことかというと、ブラウザが処理しなければならないデータ量は1/3になり、さらにダウンロードサイズはおよそ3/4にすることが出来たというわけです。当然、削減効率自体はプロジェクトによって左右しますが、UnityのWebGL機能をつかうプロジェクトでは、全体的に同傾向の改善が見られることを期待しています。
WebAssemblyについてさらに知りたい場合は、こちらのFAQをご覧下さい。

このアナウンスメントに続いて、現在のWebGLに対する開発の状況や、次の一年間のうちに私たちが期待しているエコシステムの変化についても共有したいと思います。
たとえば、私たちは現在、さらなるビルドサイズの改善、SIMD.js対応、 Shared Array Buffers 対応 ( JavaScriptにマルチスレッド機能を提供します ) そしてWebGL 2.0 などに取り組んでいます。もっと詳しくお知りになりたい方は、ぜひ WebGL Roadmap フォーラム もチェックしてみてください。そちらにはより多くの情報を掲載しています。

もし、来週欧州で行われる Unite アムステルダム にお越しの方は水曜日の私のWebGLに関するセッションにご参加頂くか、ハンズオンラボに来て質問をいただければと思います。

23 replies on “WebGL: WebAssembly と今後のロードマップについて”

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 playadnc.com 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.