Search Unity

Будущее сжатия данных в Unity

, 16 декабря, 2015

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

Меня зовут Рик Гельдрайх (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

23 replies on “Будущее сжатия данных в Unity”

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.

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.

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)

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?

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?

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

[…] you’re a Unity developer you might appreciate today’s blog post from Unity principal engineer (and occasioanl Gamasutra blogger) Rich Geldreich detailing how the […]

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

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.

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.

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.

Comments are closed.