Неужели мой случай настолько отличается от реальности? Сорок против трёх, это же на порядок меньше!
А что у вас в браузерной консоли? Есть там какие-нибудь краши?
Blend4Web vs Unity: Сравнение работы WebGL
2016-10-21
Предисловие редактора
Первоначально этот материал был опубликован на популярном ресурсе для IT-специалистов Хабрахабр. Животрепещущая тема вызвала интерес у тысяч читателей и вылилась в десятки самых различных комментариев, в том числе были указаны некоторые важные недостатки в системе тестирования. Предлагаем вашему вниманию обновленные тесты сравнения Unity WebGL и Blend4Web, где были учтены выявленные недостатки, а сами проекты адаптированы для новейших релизов обоих движков.
Вступление
В декабре 2015 года разработчики Unity объявили о WebGL, как об «официально поддерживаемой платформе». С этого момента, можно считать Unity конкурирующим игроком на поле WebGL. Поэтому интересно было бы сравнить функциональность, зрелость и работоспособность этих технологий.
Мною были сделаны три тестовые программы различной сложности. Приложения готовились одновременно для обоих движков и являются симметричными. Сцены, объекты, текстуры и даже настройки материалов — всё практически идентично. Ни один движок не получил форы или специальных оптимизаций. То, что предлагалось «из коробки» — использовалось по умолчанию.
Хотя в некоторых случаях приходилось импровизировать. Так, для сборок приложений Unity в файлы HTML была добавлена строка кода (имеющаяся в аналогичных файлах Blend4Web), которая уменьшает разрешение области отрисовки на мобильных устройствах:
<meta name="viewport" content="initial-scale=1.0, user-scalable=no, width=device-width">
Все сцены и модели предварительно готовились в Blender, текстурировались и целиком отдавались движкам. В некоторых случаях я использовал пустышки (Empty) для точной установки тех объектов, что не «видит» Unity в файлах blend. Это источники света, а также камеры.
Сравнение выполнялось по нескольким критериям: скорость загрузки, FPS (кадры в секунду), потребление памяти. Обратите внимание, что «скорость загрузки» высчитывалась дважды: «холодный старт» при очищенном кэше браузера и «горячий старт», когда основные данные берутся из кэша. Эти критерии позволят определить, какой движок быстрее и эффективнее начнет отображать сцену в браузере. Люди очень не любят долго ждать...
В тестировании использовались: PC (Intel I5-3570, 8RAM, GTX 650 при разрешении экрана 1680х1050), Apple iPad 3, Motorola Nexus 6, Samsung Galaxy S6 Edge, браузер - Google Chrome 53 (на iPad - Safari 10).
Тест №1
Это очень простая сцена, похожая на кадр из какой-нибудь игры. Несколько моделей, пара источников света, простейшая анимация. Здесь не используются крутые технологии.
Здесь получился очень интересный результат. Видно, что приложения Blend4Web загружались быстрее, чем сцены Unity.
Тест 1. Время загрузки, холодный старт (секунды, меньше - лучше).
Дело в том, что по умолчанию Unity выполняет сжатие контента при сборке проекта WebGL. После скачивания архивов происходит распаковка уже на стороне клиента. Разумеется, на это требуется время. Добавьте сюда демонстрацию обязательного загрузочного экрана (еще несколько секунд) и инициализацию WebGL. Особенно хорошо видна разница работы двух движков в результатах второй таблицы.
Тест 1. Время загрузки, горячий старт (секунды, меньше - лучше).
Это «чистое» время необходимое движкам для отображения загруженной сцены. Blend4Web справляется практически моментально, в то время как его конкурент тратит в среднем в шесть раз больше. Конечно, можно немного сократить время загрузки, если отказаться от бесплатной Unity Personal и перейти на платные версии. Но вам вряд ли удастся убыстрить сам процесс инициализации.
Тест 1. Скорость отрисовки (кадры в секунду, больше - лучше).
Всеми нами любимые FPS. Это очень важный параметр. Никому не нравятся приложения с дерганной и тормознутой картинкой.
Здесь Blend4Web и Unity практически «дышат ноздря в ноздрю», но только в тесте на PC. На мобильных устройствах скорость приложений Blend4Web «упиралась в потолок» - 60 кадров в секунду. К сожалению, не нашлось способа отключения ограничения FPS для мобильных браузеров, в то время как Google Chrome на Windows запускался с параметром «--disable-gpu-vsync».
Несколько иная картина у Unity. Из мобильных устройств только Galaxy S6 продемонстрировал солидный результат. Apple iPad 3 «показал» всего 9 единиц, а устройство от Motorolla вообще не смогло загрузить и отобразить тестовую сцену.
Тест 1. Потребление памяти (Мб, меньше - лучше).
Данные по расходу памяти брались из Task Manager браузера Google Chrome для настольного компьютера. Как видите, оба движка показали очень хорошие результаты.
Признаюсь, я ожидал увидеть немного иную картину, которая могла бы объяснить падение браузера для приложения Unity. Но, как показали тесты, особой разницы в расходовании памяти нет, по крайне мере для этой сцены. Тем удивительней факт падения браузера в Nexus для такой примитивной сцены.
Тест №2
Итак, сцена «Остров в океане». Неоптимизированная, тяжелая, очень большая. Поверьте, я не «подгонял» ее для мобильных систем!
В этой сцене основную сложность составило именно синхронизация внешнего вида для обоих движков. С Blend4Web все понятно — модели и ландшафт создавались в Blender, там же выполнялась настройка воды и окружения. Всё как-то гладко прошло и особых затруднений не возникло.
С Unity же были проблемы. Во-первых, я отказался от использования встроенного terrain. Заселять деревьями и раскрашивать его одно удовольствие, но, несмотря на мощь этого решения, внутренний terrain может излишне тормозить. Поэтому использовалась сцена целиком из Blender с моделью ландшафта и заранее расставленными объектами. В этом случае удалось добиться максимально одинаковых сцен.
Во-вторых, стандартные шейдеры Unity не умеют работать с двухсторонними материалами и листва деревьев просвечивала с обратной стороны. Попытки использовать встроенные шейдеры типа «tree leaves» почему-то успехом не увенчались. Я не стал разбираться с этим и нашел в сети Интернет самописный шейдер, который прекрасно справился с поставленной задачей.
Но давайте перейдем к результатам испытаний, а они оказались ошеломляющими!
Тест 2. Время загрузки, холодный старт (секунды, меньше - лучше).
Тест 2. Время загрузки, горячий старт (секунды, меньше - лучше).
Первое, это опять-таки краш браузера устройства Nexus при запуске приложения Unity. А также очень долгая, неприлично долгая загрузка контента у Unity. Интересно, что временная разница между «холодными» и «горячими» результатами у этого движка в общем-то несущественная. Похоже, Unity баснословное время тратит именно на подготовку сцены для демонстрации.
Тест 2. Скорость отрисовки (кадры в секунду, больше - лучше).
Этот тест показал весьма любопытные результаты в плане быстродействия. Показания FPS у Galaxy получились одинаковыми для обоих движков, в то время, как для PC разница была очень большой. Интересно, что динамика FPS при изменении масштаба сцены у разных движков разнилась. Так, у Unity, наиболее высокое значение получалось при удалении камеры от острова. Blend4Web выдавал лучший результат, наоборот, при максимальном приближении. Очевидно, движки используют разные алгоритмы оптимизации. Поэтому в таблице указаны максимально возможные FPS в наиболее благоприятных ракурсах для движков.
Теперь насчет неожиданного краша Apple iPad 3... Как вы видите, к Nexus прибавился и этот девайс. В отличие от стандартно «лежащей» мотороллы, iPad сопротивлялся до последнего и слетал уже на самой сцене. Так что, замерить загрузку удалось, но, увы, работоспособность приложения Unity здесь оказалась нулевая.
Возможно, разгадка кроется в результатах следующей таблицы.
Тест 2. Потребление памяти (Мб, меньше - лучше).
Тест №3
Я не смог пройти мимо использования физики и последний тест посвящен именно ей. В сцене имеется объект с замкнутым пространством, в котором находится несколько десятков шариков. Куб медленно вращается, тем самым заставляя шарики перекатываться.
Здесь нет каких-либо сложных шейдеров или эффектов. Используется rigid body и простые коллайдеры.
Как обычно, работоспособность физики в сцене потребовала определенных усилий. Вы, наверное, уже догадались в чем была проблема?
Шарики упорно стремились покинуть свою клетку и банально высыпались за ее пределы. Это касалось обоих движков. В конце-концов было найдено приемлемое качество работы для платформы PC, когда все объекты вели себя как запланировано, но вот на мобильных устройствах, эта сцена иногда выглядела дико. Поэтому был введен новый критерий тестирования — стабильность физики или, как я его еще назвал, — «шарики-аутсайдеры». Сцена работала в течение минуты, а затем проверялись оставшиеся объекты в клетке. Чем больше потерялось, тем хуже результат.
А теперь...
Тест 3. Время загрузки, холодный старт (секунды, меньше - лучше).
Тест 3. Время загрузки, горячий старт (секунды, меньше - лучше).
Тест 3. Скорость отрисовки (кадры в секунду, больше - лучше).
Обратите внимание на одинаковые показатели FPS для сцены Blend4Web на мобильных устройствах. Логично предположить, что движок может выдать гораздо больше FPS, нежели 60, которые ограничены вертикальной синхронизацией. Дело в том, что Blend4Web умеет обрабатывать физику в отдельном потоке (worker). Насколько я знаю, Unity на это неспособна. Именно здесь кроется столь высокий FPS и, как вы дальше увидите, хорошие результаты по критерию «стабильность».
Тест 3. Стабильность физики (проценты количества выпавших объектов, меньше -лучше).
Как и говорилось, Unity и Blend4Web очень хорошо показали себя для платформы PC. Все шарики остались на месте.
Среди мобильных устройств лидером оказался Galaxy S6 (Blend4Web), а аутсайдером стал iPad 3 (Blend4Web). Приложение Unity по этому критерию тест провалило, за исключением платформы PC.
Вообще, от физики Unity в WebGL осталось очень плохое впечатление. После загрузки сцены происходило торможение экрана и лишь через пару секунд набирались столь долгожданные FPS. Разумеется, это касается только PC. На мобильных устройствах все было гораздо плачевнее. За несколько секунд терялось большинство шариков и лишь после этого набирались долгожданные 60 кадров в секунду при практически пустой сцене.
Вполне вероятно, что ответ на столь вопиющее поведение физики в случае Unity кроется в следующих результатах теста памяти.
Тест 3. Потребление памяти (Мб, меньше - лучше).
По сравнению с первыми двумя, третья сцена оказалась самой прожорливой по использованию памяти. И это касается обоих движков.
Очень странным было поведение приложения Unity. После запуска сцены расход памяти скакнул до 700 мб и лишь через несколько секунд упал до 400. Понятное дело, что за это время маломощные мобильные девайсы уже растеряли все шарики. Поэтому данные FPS для этой части устройств неверные, ибо крутился на экране уже пустой куб без каких-либо объектов.
Я не знаю, чем объяснить такое поведение, но физика в Unity WebGL показала себя не в лучшем виде.
В завершение
Результаты тестирования получились любопытными и должны быть интересными не только пользователям, но и самим разработчикам.
Ссылки на тестовые сцены привожу ниже. Ссылки на тесты приложений Unity работоспособные, просто не видно загрузчик. Учтите, что загрузка у Unity идёт гораздо медленнее.
Тестируйте, делитесь результатами!
