Search Unity

きたるUnity 5.3のリリースはUnity 5.xの中でWebGL出力をサポートする4つ目のリリースになります。私たちは最初にUnity 5.0でプレビュー版としてWebGL出力をサポートしてからいままでで大幅な進捗がありましたので、今日はこのアップデートについて共有します。

Unity 5.3での変更点

Unity 5.3はWebGL開発者にとって関係のある数々のアップデートが投入されています:

  • UnityのスタンダードシェーダーはWebGLでもデスクトップ用のものと同じ品質のリフレクション関数を使用するようになりました。Unity WebGLは今まで、モバイルのOpenGL ES 2.0向けに単純化されたスタンダードシェーダーを使用していましたが、5.3からデスクトップ用のものと同じ機能を使うようになったため、見た目のクオリティが格段に向上しました。
  • ソフトシャドウをサポートしました。
  • Unity WebGLはサーバー側で圧縮の設定がされていない場合でも、自分で適切に圧縮をハンドリングするようになりました。以前のバージョンでは、WebGLはホストするWebサーバーがgzip圧縮されたファイルを適切にクライアントに送信するように設定しておく必要がありました。それが行われていない場合、非圧縮のデータを送信することになり、ダウンロードサイズが本来あるべきサイズよりも何倍にもなってしまっていました。結局サーバーの設定を適切に行うのは難しい場合があるということがわかってきたので、私たちのWebGLランタイムはWebサーバーが圧縮データを送信できるように設定されていない場合でも、自動的にgzip圧縮されたバージョンのデータをWebサーバーからダウンロードするようにしました。ランタイムはデータのダウンロードを行うと、クライアント側でgzipの解凍を行います。これはプロトコルレベルで圧縮対応が適切に処理されている状態と比べるとすこし余計な時間がかかるのですが、それでも利用者の皆さんが巨大なダウンロードを避けるためにサーバーのマニュアルを熟読してなんとかする必要がなくなりました。ちなみにこの対応が入った今でも、Webサーバーの設定を適切に行っておけば以前と同じように圧縮対応はプロトコルレベルで適切に処理されます。(配信サイズについてはこちらをご覧ください).
  • ゲームに使用するアセットデータがメモリ内にLZ4圧縮されて保持されるようになりました。WebGLでは、実際にファイルシステムがあるわけではありません。このため、すべてのアセットはずっとメモリに置かれています。Unity 5.3ではメモリ内のアセットデータはLZ4を使用して圧縮されており、アセットがロードされるときにのみ解凍されます。これはアセットデータがより少ないメモリを消費するということで、メモリ不足になるリスクがより小さくなりました。
  • WebGLでビルドされたファイルがより簡単に異なるURL上に持っていけるようになりました。ビルドプロセスで生成されるすべてのファイルは生成されたindex.htmlファイルから直接参照されます。設定が必要なURLがすべて一つのファイルに集約されたので、ビルドしたデータを別のサーバーに持って行くのが簡単になりました。(ビルド出力を移動したい場合は、こちらを参照してください)
  • WebGLはさらに、Unity Cloud Buildで選択可能なプラットフォームとなりました。チームメンバーは直接ゲームやアプリケーションをブラウザからテストすることができます。
  • ドキュメントの改善。Unity 5.3ではWebGLのドキュメントを改修し、たくさんの情報を追加しました。いまのWebGLで何ができて何ができないのか、あるいは特定のブラウザーでのみサポートされている機能は何か、といったことは現状ではとても大事なことなので、これがわかるように詳しい情報を記載しました。
  • 数々のバグ修正。Unity 5.3はUnity 5.2から、28のWebGLに関するバグを修正しています。さらに、ほかにも(WebGL特有というわけではないが)WebGLユーザーにメリットをもたらす修正が含まれています。また、Unity 5.2.xのパッチリリースの中で対応してきたいくつかのWebGL関連バグの修正もすべてUnity 5.3に含まれています。

WebGLはUnityの正式なビルドターゲットに

これまでUnityのWebGL機能は非サポートのプレビュー版機能として提供されてきました。Unity 5.3にて、わたしたちはこの「プレビュー」の表記を落とし、正式にサポートされたビルドターゲットに昇格します。プレミアムサポート、およびエンタープライズサポートプランは、今後WebGLをサポート対象としてカバーします。

Unity 5.3は上記で書かれたような沢山の改善をWebGL開発者に提供します。また、5.2および5.1のサイクルでも、同じように数々の改善を行ってきました。わたしたちはUnityのWebGL機能が5.0以来長い道のりを乗り越えてきたと感じています。同じように、ブラウザーテクノロジーもこの期間で改善されていきました。MicrosoftはWindows 10でasm.jsをサポートする新しいEdge ブラウザーをリリースし、UnityのWebGLコンテンツの実行速度はかつてのInternet Explorer 11に比べて大幅に高速になりました。UnityのWebGLコンテンツを楽しめる人々の潜在的な総数が今までよりも広がったのは間違いありません。

WebGLプラットフォームは5.0でPreview版をリリースしたときに比べて大幅に良くなりました。ただし、これはUnityの全ての機能が突然WebGLで動作するようになったという訳でもなければ、パフォーマンスがデスクトップ向けのビルドと遜色ない速度になったわけでも、全てのブラウザーでコンテンツが再生できるようになったわけでもありません。これらのすべてのエリアで改善が見られていますが、あくまで一歩一歩良くなっているのです。そうした課題はありつつも全体としてみると私たちのWebGL機能はこのプラットフォームの制約の中ではかなり上手く動作するようになったと思いましたので、今がWebGLを正式なビルドターゲットとするべき時だと考えたのです。その分、私たちはドキュメントに力を入れてどういった制約事項があり、どのブラウザーでどの程度の期待ができるのかといったことをよく分かるようにしました。

ブラウザーベンダーとの協力

私たちのWebGL出力機能はブラウザーのWeb技術に大きく頼っています。私たちは過去数年間、ブラウザーベンダー大手3社と密接に協力し、これらのテクノロジーの改善に貢献してきました。

Mozillaのプラットフォームプロダクト マネージメントディレクターである Martin Best氏は「MozillaはUnityが次のステップに進みWebGL出力機能に対する正式なサポートを提供することをとても嬉しく思います。私たちはasm.js、WebGLやEmscriptenと言った多くの基盤となるWebテクノロジーを創始し、こうしたことを可能にしました。私たちはUnityや他のブラウザーベンダーと密接に関わっていき、最高のWebゲーム体験を実現していきます」 と言っています。より詳しくはMozillaのブログでお読みいただけます。

Microsoftでは、EdgeおよびOpen Web Standards のプリンシパル プログラムマネージャーのDavid Catuhe氏が: 「Microsoft EdgeにとってWebGLとasm.jsはWindows 10ユーザーに完全なWeb体験を提供する重要な要素です。WebGLビルドターゲットをリリースすることで、Unityはデベロッパーが素晴らしいゲーム体験を私たちのユーザーに、Webを通して提供する能力を与えてくれます。私たちにとってもUnityと共に仕事をして、WebGL、asm.jsやその他の機能強化をWebプラットフォームに提供していくことはまたとない機会です」とコメントを寄せています。

Google ChromeのWebGLチームであるBrandon Jones氏、Zhenyao Mo氏 と Ken Russell氏はデベロッパーコミュニティに向けて同様の意見を表明しています:「UnityのHTML5およびWebGL出力サポートはこのエコシステムの中で最もエキサイティングなことの一つです。世界中のデベロッパーがUnityを使って素晴らしいコンテンツをWebに持ち込むでしょう。私たちは今後も継続してWebプラットフォームのパフォーマンスと機能を改善し、さらにエキサイティングなインタラクティブコンテンツを可能にしていきます」

さあ、あなたのターンです

私たちはUnityのWebGL出力機能がWebのゲームの未来だと信じています。Heroes Of ParagonSpider BoxBig Buck Hunterのように、UnityのWebGL出力を使ったすでにリリース済タイトルも出てきています。このリストにあなたのゲームの名も連ねましょう!

始めるには:

32 コメント

コメントの配信登録

コメント受付を終了しました。

  1. 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. Any closer on WebGL for Mobile device browsers?

  3. Barney LaHaye

    12月 9, 2015 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. I build game for WebGL, and shwadow still pixeled, not soft, why ?

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

    1. Jonas Echterhoff

      12月 9, 2015 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. You can with the 3rd party library Coherent: http://coherent-labs.com/

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

  7. 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. Good news!!
    I am interesting it.

  9. Luis Eduardo Nery Santos

    12月 8, 2015 7:54 pm

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

  10. 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. Great News!

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

    1. Jonas Echterhoff

      12月 8, 2015 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

    12月 7, 2015 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

      12月 8, 2015 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. “WebGL in Unity Cloud Build is now a platform option. Team members can directly test the game/application in the browser.” YYYAAAAAAAYYYY!!!! ^_^

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

      12月 8, 2015 3:26 pm

      It is live now.

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

        12月 7, 2015 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. 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

      12月 7, 2015 7:21 pm

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

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

    Thanks and great work!

    1. Jonas Echterhoff

      12月 7, 2015 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. So web workers don’t work for your needs and it means you’ll need something like WebAssembly to implement correctly?

        1. Jonas Echterhoff

          12月 7, 2015 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. 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. 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. 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.