Search Unity

Здравствуйте!

Меня зовут Рик Гельдрайх (Rich Geldreich), я разработчик игр, графический программист и специалист по сжатию данных.  Я работаю в игровой индустрии более 20 лет; за это время я участвовал в создании, оптимизации и улучшении различных игровых движков в таких компаниях, как Ensemble Studios (Microsoft) и Valve.

На протяжении этих лет, обычно по ночам между выпуском игр, я работал над несколькими библиотеками сжатия данных, предназначенным для разработчиков игр. Некоторых из них имеют открытый код, другие — закрытый. Среди них были такие, как crunch, LZHAM, miniz и jpeg-compressor. Еще я написал picojpeg — декодер для JPEG-изображений, оптимизированный для маломощных встроенных 8-битных процессоров. Эти библиотеки применяются не только в играх, но и в других интересных приложениях: picosatellites, доставке контента WebGL, декодировании UHD-видео с помощью графического процессора, а также в обучающих программах.

Что такое сжатие и зачем оно нам нужно

Мировой специалист Мэтт Мэхони сформулировал определение сжатия данных таким образом: «Искусство уменьшения количества битов, необходимого для хранения или передачи данных». Значимость этой технологии трудно переоценить: она экономит время, уменьшает загруженность постоянной и оперативной памяти и каналов связи. С помощью сжатия возможно решение задач, которые в противном случае считались бы непрактичными или неэкономичными с учетом существующих возможностей по хранению, передаче и обработке информации.

Существует два основных класса систем сжатия данных: специализированные системы, допускающие потерю данных в определенных пределах (JPEG, MP3) и не допускающие потерь (ZIP). Эти классы подразделяются на огромное количество подходов, алгоритмов и приложений. Некоторые наиболее значимые системы входят в мировые стандарты и включаются в вычислительное оборудование на аппаратном уровне.

Unity использует как сторонние, так и собственные алгоритмы сжатия для обработки звуков, текстур, анимации и пакетов ресурсов. Без них объем памяти, необходимый для функционирования Unity, был бы непрактично велик — особенно для мобильных устройств.

Одна из задач команды Data Compression Team — настройка и оптимизация используемого набора систем сжатия данных. В настоящее время создается новая офлайн-система сжатия двоичной информации с использованием дельта-кодирования для внутреннего использования командами Unity. Также поставлена долговременная задача: исследование всей платформы Unity с целью определить, каким образом можно ликвидировать программные ограничения, которые понижают эффективность сжатия данных.

Чего мы добились

Присоединившись к Unity, я вместе с Александром Суворовым занялся изучением технологий сжатия, не допускающих потерь. Такое сжатие используется, например, для скачиваемых пакетов данных Unity. Целью работы было определение текущего состояния технологии и составление прогнозов о развитии. Особое внимание мы уделили сжатию текстур с помощью графического процессора.

Мы разработали нашу первую библиотеку сжатия данных с использованием дельта-алгоритмов, пригодную для мобильных устройств. Unity использует эту библиотеку для эффективной передачи «нового» набора данных при наличии связанного «старого» набора на обоих сторонах передачи. Кроме того, мы испытываем версию не допускающего потерь компрессора LZHAM, использующую JavaScript и предназначенную для сетевых приложений.

Изучая технологии сжатия без потерь мы нашли возможность, которая может быть включена в существующие системы сжатия для быстрого создания новых индивидуальных систем сжатия текстур, геометрии и анимации. Мы также рассматриваем возможность применения новых принципов передачи данных системам сжатия без потерь. Продуктивно обсудив все это с командами Unity Cloud Build и Services, мы приступили к исследованию возможности перевода используемой в сейчас офлайн-системы сжатия данных с использованием дельта-алгоритмов в режим реального времени.

Наконец, мы нашли ключевую задачу, которую команда Data Compression Team будет решать в долгосрочной перспективе: создать новые системы сжатия, допускающие и не допускающие потери, оптимизированные специально для работы с данными Unity

Комментарии закрыты.

  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. 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. 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. 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. 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. 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. 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. I think this is a great idea!

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

    1. Thanks a lot Tuti!