Search Unity

こんにちは皆さん!


私はRich Geldreichといいます。私はゲーム開発者で、グラフィックプログラマーで、そしてデータ圧縮の専門家です。わたしはこれまで20年以上にわたってEnsemble Studios (Microsoft)やValveといった会社でいくつかの主要なゲームエンジンの開発や最適化、そして強化の最前線に立ってきました。

また、この数年間ゲームをリリースする合間に、クローズドあるいやオープンソース問わず、いくつかのゲーム開発者向けの圧縮ライブラリーの開発に取り組んできました。crunchLZHAMminizjpeg-compressorなんかがそうです。picojpeg というメモリーの極端に少ない8bitの組み込みCPU向けに最適化したJPEGデコーダーを書いた事もあります。ゲーム以外の領域だと、これらのライブラリーは驚くほど多くの種類の面白いアプリケーションで活用されています。例えばWebGLのコンテンツ配信用に作られたpicosatellitesやGPUに最適化されたUHD videoデコーディングなどがそうです。その他、教材としても活用されています。

UnityではわたしとWebGLチームのAlexander Suvorov が、驚くほど広く深い、データ圧縮の領域を担当します。

で、圧縮って何?なんで重要なの?


世界随一のデータ圧縮エキスパートである
Matt Mahoneyによると、データ圧縮というのは「保存・もしくは送信するデータのビット数を削減する技術」です。さまざまなレベルで圧縮というのは必要不可欠な技術で、時間を節約したり、ストレージの容量を節約したり、メモリーの利用効率を高めたり、通信の使用バンド幅を削減したりといったことを可能にします。圧縮はハードウェアやストレージ、データ送信のリソースを鑑みたときにそれまでは非現実的であったり採算の取れなかったようなことを可能にします。

圧縮システムには大きくわけで2つの種類があります。一つは特定用途に特化したJPEGやMP3などといった非可逆な技術、もう一つはZIPのような汎用に使える可逆な技術です。この2つのカテゴリーの中には果てしないバラエティーのアプリケーション、アプローチと特定用途に特化したアルゴリズムが存在します。その中からいくつか、最も重要かつ価値の高いシステムが世界標準となり、専用の回路によってハードウェアで直接実装されています。

Unity内部に結成された私たちデータ圧縮チームは、データ圧縮に関することすべてを担当します。内部的には、サウンド、テクスチャー、アニメーション、メッシュ、アセットバンドルなどの領域で、Unityは独自技術・既存技術問わず、すでに数々のゲームアセット向けの圧縮システムを活用しています。言うまでもなく、これらの圧縮システムなしにUnityは多くのプラットフォームで全く使い物にならないようなメモリー使用量を要求することになってしまいます。モバイルデバイスでは特にそうです。

わたしたちのチームの責任の一つは、すでに現在利用している圧縮システムをチューニング・最適化し、適切な状態に保つことです。近い将来、私たちは新しいオフライン&リアルタイムの汎用バイナリデータ差分圧縮機能をUnityの内部のいくつかのチームと一緒に実装していきます。圧縮チームの最も重要な長期的ゴールはUnity全体のソフトウェアスタックを見直し、どのように分割していけば設計上の障害を取り除いて最高の圧縮ソリューションを導入できるかを見極めることにあります。

現在までの進展


Unityの一員になって以来、Alexander Suvorovとわたしは現在の可逆圧縮の世界を深く調査していきました。可逆圧縮技術はUnityがダウンロード可能なアセットバンドルファイルが必要とするディスク容量やダウンロード時間を大きく削ることが出来るようにします。私たちのゴールは
最新技術がどうなっているのかを確認するだけでなく、この分野がどこに向かうかを予測することでした。さらに、私たちはGPUテクスチャー圧縮に関する長期的な展望についても話し合いました。

実務的には、私たちは最初のモバイルフレンドリーなバイナリ差分データ圧縮(または「ファイルパッチング」の)ライブラリーを開発し、分析を始めました。この独立したライブラリーはUnityが、とある2点間で(できれば関連のある)「古い」データを持つ相手に対して「新しい」データを効率的に送信する必要があるときに利用出来ます。最後に、私たちはWebアプリケーション用にJavascript版のLZHAM可逆データコンプレッサーをテストし始めました。

可逆圧縮技術の調査中、私たちは新しいタイプのカスタムテクスチャー、ジオメトリーとアニメーションの圧縮が出来る機能が、現在の可逆圧縮にすぐに追加できることを発見しました。さらに私たちはそもそもデータがどのように可逆圧縮処理に投入されるべきかの流れを完全に再定義することも検討しています。また、UnityのCloud Buildやサービスチームの開発者との素晴らしいディスカッションの結果、現在の開発しているオフライン用のバイナリ差分データ圧縮機能をどのようにすればリアルタイムで動作させることが可能かのリサーチも始めました。

これらの仕事を通して、圧縮チームが取り組むべき長期的なポイントはUnityとよりよくコミニュケーションできるデータ圧縮エンジンをどうやって開発するか?ということだというのが見えてきました。長期的なゴールでは、Unityのデータに最適化された新しい不可逆圧縮および可逆圧縮のエンジンをいくつも開発していくことになるでしょう。

とにかく、非常にエキサイティングな時代がUnityで始まっています!これからの展開が待ちきれません。

23 コメント

コメントの配信登録

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

  1. Rich, if you are working with compression please take a look at this idea, and my comment in particular:
    https://feedback.unity3d.com/suggestions/editor-display-asset-bundles-in

    It involves asset bundles and would probably require a rewrite for it to work. But its an interesting feature to have and could have a lot of applications for dev-to-dev and dev-to-prosumer/orWhatnot exchanges.

    Regardless, good luck with your work, we all appreciate what you do.

  2. Great plans!
    But what about compression in current Unity branches? Is it possible to send/receive network traffic, for example via WWW class, using standard gzip/deflate algorithms? Natively, without 3rd-party libraries or plugins.

  3. I hope you guys focus on Android (which has APK limitations) and iOS first. I believe these 2 platforms are to focus first so that we can have something soon. (I hope)

  4. Welcome Rich! It sounds like you are deep into image compression. Did you have a look at the HAP codec? AVPro Windows Media from the Asset Store supports this and I am using it frequently. Why not make the HAP codec run natively in Unity?
    https://github.com/vidvox/hap
    https://www.assetstore.unity3d.com/en/#!/content/2546

  5. Thank you for the useful information! Our company experts greatly appreciate it! Have you already estimated the time that you need to create a data compression engine that will be perfect for Unity? When can we expect the first release?

  6. Just wanted to add my support for better iOS data compression of some sort. My old Cocos2d game has a 50MB installed size. I converted and upgraded that game to Unity, but it now has a 500MB installed size due mostly to uncompressed textures. I’m not going to release this update because that’s too much of a size increase to impose on my users. Maybe the solution that Matt suggested above here is what people in my situation need? If the data compression you talk about in the article is the solution, then that’s great, but how long will that take to get out the door?

  7. Do you guys feel that Google’s brotli could prove beneficial for Unity-based game deployments?

    1. Rich Geldreich

      12月 17, 2015 7:55 pm

      Google’s Brotli codec looks very promising. Over the holidays I’ll be conducting a series of tests comparing Brotli with some other commercial and open source codecs, on a wide variety of test data.

  8. Wow!!
    so many things that i have been hoping to see for years in unity are being announced one after the other :D !!
    you guys are making great work ! keep it up and best of luck :)

  9. Nice.

    One feature relate to data and compression that can be great to have is the ability to know an asset’s size for the built platform. For example – how much does a texture take ? A prefab? A scene?

    The build log prints a list of assets sorted by their size, but this is the uncompressed size so it’s pretty meaningless…

    BTW not sure this feature is even possible to develop :)

    1. We are actually working on a build reporting feature, that extracts exactly such data for you.

      1. Awesome !! bring it on !!

    2. Alejandro Gonzalez

      12月 19, 2015 2:33 pm

      On that note another great feature would be to add the compressed byte size to the asset bundle manifest so that loading bars developers can easily estimate the size to download a set of many bundles making progress bars friendlier and more accurate.

  10. That’s great and all, but maybe you could spend a few days implementing this feedback item first. Currently, it’s nearly impossible to have an acceptable build size AND nice looking graphics (ie, no banding or compression artifacts) for mobile games. People have resorted to work-arounds like loading PNG files from Resources at runtime but then you lose out on all the other nice Unity features for those assets. Even if this compression team plans to handle this situation in the future, I bet it’ll be many months, maybe years before a solution is integrated and we need a solution sooner than that.

    1. Rich Geldreich

      12月 16, 2015 7:35 pm

      Hi Matt – Thanks for pointing this out. I recently helped ship a large mobile game using Unity, so I understand how important this is. Let me investigate the situation.

      1. Thanks for looking into it!

  11. imaginaryhuman

    12月 16, 2015 6:41 pm

    Cool. While you’re at it, can you please make available some kind of fast/capable data compression for use in scripting… such as lzma or better… ie to compress and/or decompress a byte array at runtime. Then I/we can dabble with implementing our own compression schemes on our own data, not just on Unity’s data.

    1. Rich Geldreich

      12月 16, 2015 7:01 pm

      Got any examples of the usage cases, so we can better understand your needs?

      1. Voxel objects with a few byte of data per block.
        (Currently using Mike Krueger’s GZipInputStream c# library.)

      2. imaginaryhuman

        12月 17, 2015 3:47 pm

        Just custom data mainly, arrays of data that maybe I precalculated to save runtime performance, that I want to then expand at runtime. It could be texture data or maybe a level. For example to load a losslessly compressed image at runtime without it having to be stored in an expanded texture format for e.g. for 2d graphics. Or maybe there’s some data file that I created, maybe it represents colors or a precalculated animation or something. Typically it’s a byte array.

        I’d also like to see compression used in build targets like windows/mac and web to get the file sizes down to help with download speed.

        1. Rich Geldreich

          12月 18, 2015 12:00 am

          I think this is a great idea!

  12. Wish best of luck to you, Alexander and Rich.

    1. Rich Geldreich

      12月 16, 2015 7:03 pm

      Thanks a lot Tuti!