Blend4Web vs Unity. Битва на рингу. Раунд 2

Чергові «папуги»?! О, ні. Три реальних тіста, три різних напрямки, різні пристрої та цікаві факти.



Пройшов рік з моменту моєї першої спроби порівняння Blend4Web і Unity. Кілька наївна стаття викликала шквал коментарів, де прихильники движків, як і годиться, зайняли діаметральні боку. Багато чого змінилося з того часу — Unity WebGL вже не бета, Blend4Web зміцнів і змужнів, а ваш покірний слуга набрався певного досвіду.

Як ви зрозуміли, я повертаюся до теми порівняння Blend4Web і Unity на полі битви через Інтернет». Мене не цікавить зручність роботи або функціональність движків. Тільки результат, тільки хардкор і тільки веб-браузери. Я не збираюся розводити холівар на тему «хто крутіший». Реальні тести і реальні цифри. Ви завжди можете перевірити на своїх пристроях і відписатися в коментарях, а тепер приступимо…

Підготовка до тестів
Дуже складно проводити тестове порівняння абсолютно різних програмних інструментів. Потрібно враховувати безліч нюансів і намагатися досягти симетричних проектів і налаштувань, починаючи від розташування об'єктів і закінчуючи параметрами кінцевого експорту.

В якості базового конструктора сцен був обраний Blender і цьому є кілька причин. По-перше, Unity прекрасно імпортує нативні файли Blender. Не потрібно ніяких експортерів FBX і ручної установки об'єктів у редакторі. По-друге, для Blend4Web — це єдиний спосіб створення сцени.

Тому, всі сцени і моделі попередньо готувалися в Blender, текстурировались і цілком віддавалися движка. У деяких випадках я використовував пустушки (Empty) для точної установки тих об'єктів, що не «бачить» Unity у файлах blend. Це джерела світла, а також камери.

Всі текстури, особливості налаштування матеріалів (Diffuse, Normal map тощо) практично дзеркально переносилися з проекту в проект. Про деяких моментах я розповім пізніше.

Також використовувались базові інструменти і можливості движків для створення оточення, деяких ландшафтних ефектів, налаштування освітлення та тіней. Я намагався добитися повної ідентичності сприйняття одних і тих же сцен для обох движків. Правда, не скрізь це вдавалося, і ви помітите деякі розбіжності.

В якості основних критеріїв були вибрані наступні пункти:

  • Час «холодної» завантаження. Від моменту активації в адресному рядку до появи тестовій сцени.
Це дуже важливо для браузерних додатків. Звичайно, багато залежить від налаштувань сервера, оптимізації додатків і швидкості з'єднання. Для коректного тестування даної опції, я вирішив залишити пропоновані параметри експорту за замовчуванням. Так, Unity виконує розархівування даних на льоту, а Blend4Web вирішення цього питання повністю «перекладає на плечі» розробника. Сам тестовий сервер відсилає файли «як є», без усякого стиснення.

З одного боку здається, що у Unity вже є явна перевага перед Blend4Web, але, насправді, тут теж є свої «підводні камені».

  • Час «гарячої» завантаження. Як швидко движок запустить вже кешовані браузером файли.
Щоб виключити з результатів настільки неоднозначне явище, як передача даних і був придуманий цей критерій. Тепер контент завантажується з кешу браузера. Тут цікаво реальний час, необхідний движка для відображення сцени.

  • Швидкість кадрів в секунду (FPS).
Це найулюбленіше параметр всіх гравців, так і игроделы недалеко пішли! У програми були додані лічильники FPS. Для Unity використовувався цей скрипт, а Blend4Web спочатку має таку можливість.

Також для тестового браузера примусово відключалася обмеження у 60 кадрів. Так, наприклад, Google Chrome запускався з параметром --disable-gpu-vsync. Що ж стосується мобільних браузерів, то в них наявне обмеження особливої ролі не грало. Багато результати були свідомо нижче 60 кадрів в секунду.

  • Використання пам'яті. Це болюча тема для багатьох WebGL-движків.

Стабільна робота браузера багато в чому визначається витратою пам'яті на конкретну сторінку. Неакуратне поводження з пам'яттю може призвести до фарбую самого браузера, що абсолютно неприпустимо для ігор і веб-додатків. Власне, дані бралися з Task Manager браузера Google Chrome (гарячі клавіші виклику SHIFT+ESC).

В якості тестового обладнання були задіяні різні пристрої (спасибі знайомим, бо у мене деяких не було), починаючи від стаціонарного комп'ютера і закінчуючи продуктивним смартфоном.

У тестуванні використовувалися: PC (Intel I5-3570, 8RAM, GTX 650 при дозволі екрану 1680х1050), Apple iPad 3, Motorolla Nexus 6, Samsung Galaxy S6 Edge.

Досить різнобічне обладнання…

Тест №1. «Hello World!»
Традиційно програмування починається з написання програми «Hello World». Щось подібне я вирішив використовувати і для першого тесту, але дещо більш адаптоване до реалій розробки ігор.

Отже, проста сцена з кількома клонованими об'єктами. Звичайні текстури посилені Normal Map. Два джерела світла і проста анімація. Так як тести передбачається запускати і на мобільних пристроях, то були прийняті заходи для оптимізації сцени в обох движках.



Як бачите, досить стандартна сцена для якоїсь гри. Нічого складного тут не мається і таке обидва движка повинні «прожувати» без проблем. Але результати виявилися трохи не тими, що очікувалися.

Результати тесту за критерієм «Холодна завантаження»



Чим швидше завантажується програма, тим краще. Зрозуміло, тут велике значення має пропускна здатність каналу. Тому варто розглядати результати щодо один одного, а не реальні цифри. І тут з'ясовується цікава особливість — складання програми на Unity завантажується куди повільніше, ніж аналогічна від Blend4Web, а на пристрої Nexus 6 вкладка браузера несподівано «впала».

Врахуйте, що час остаточного завантаження вважалася від моменту старту в рядку браузера і до появи на екрані сцени.

Результати тесту за критерієм «Гаряча завантаження»



Другий тест демонструє швидкість запуску програми вже з кешу браузера. На свідчення не впливає швидкість з'єднання, налаштування сервера та інші параметри, а тільки готовність характеризується самого движка швидко відобразити сцену. І тут Blend4Web запускається просто стрімко, практично однаково на різних пристроях, чого не скажеш про Unity.

Якщо порівняти результати швидкості завантаження програми Unity за двома таблицями, то вимальовується дуже цікава картина — зовсім невелика різниця в часі між «холодним» і «гарячим» стартом.

Схоже, тут злий жарт зіграли особливості ініціалізації WebGL і завантаження контенту. цієї статті на хабре все чудово розписано.

Також потрібно враховувати час, витрачений Unity на демонстрацію splash-екрану. Це неотключаемая опція для версії Standard, яка у мене є. Звичайно, в платній версії движка ви вільні самі вирішувати долю заставочного екрану.

Результати тесту за критерієм «FPS»



Перше, що кидається в очі — це різка різниця між показаннями FPS для комп'ютера і мобільних пристроїв. Цілком імовірно iPad 3 може видати більше кадрів в секунду (принаймні у разі Blend4Web), але не вдалося знайти способу відключення обмежень FPS для мобільних браузерів. Втім, для очей цілком комфортно виглядає оновлення екрану і 30 одиниць.

Цікаво, що пристрій Galaxy S6 обидва движка зрівнялися в продуктивності, в той час як на iPad 3 Unity залишилася в «хвості». Шкода, звичайно, що додаток Unity повністю провалив тест на пристрої від Motorolla.

Результати тесту за критерієм «Витрата пам'яті»



Знову-таки, не вдалося знайти спосіб коректно заміряти витрата пам'яті для конкретної вкладки мобільного браузера. Тому, тут і далі тільки свідчення зняті зі стаціонарного комп'ютера. Теоретично, такі ж значення повинні бути і для мобільних браузерів.

Взагалі, я очікував побачити трохи іншу картину, яка могла б пояснити падіння браузера для програми Unity. Але, як показали тести, особливої різниці у витрачанні пам'яті не є, принаймні для цієї сцени. Тим дивовижніше факт падіння браузера в Nexus для такої примітивної сцени.

Тест №2. «Важка артилерія»
Другий тест — повна протилежність сцені з кубиком. Сотні об'єктів, великий простір, десятки текстур, тіні, більше мільйона вершин. Таке під силу буде, мабуть, тільки стаціонарного комп'ютера. Я не розраховував, що даний тест взагалі зможе запуститися на мобільних пристроях! Ніякої оптимізації спеціально під малопотужні девайси не виконувалося.



У цій сцені основну складність становить саме синхронізація зовнішнього вигляду для обох движків. З Blend4Web все зрозуміло — моделі і ландшафт створювалися в Blender, там же виконувалася налаштування води і оточення. Все якось пройшло гладко і особливих труднощів не виникло.

З Unity ж були проблеми. По-перше, я відмовився від використання вбудованого terrain. Заселяти деревами і розфарбовувати його одне задоволення, але, незважаючи на міць цього рішення, внутрішній terrain може надмірно гальмувати. Тому використовувалася сцена цілком з Blender з моделлю ландшафту і заздалегідь розставленими об'єктами. У цьому випадку вдалося домогтися максимально однакових сцен.

По-друге, стандартні шейдери Unity не вміють працювати з двосторонніми матеріалами і листя дерев просвічувала із зворотного боку. Спроби використовувати вбудовані шейдери типу «tree leaves» чомусь успіхом не увінчалися. Я не став розбиратися з цим і знайшов в мережі Інтернет самописний шейдер, який чудово впорався з поставленим завданням.

Але давайте перейдемо до результатів випробувань, а вони виявилися приголомшливими!

Результати тесту за критеріями «завантаження»





Перше, це знову-таки краш браузера пристрою Nexus при запуску програми Unity. А також дуже довга, непристойно довге завантаження вмісту у Unity. Цікаво, що тимчасова різниця між «холодними» й «гарячими» результатами цього движка загалом несуттєва. Схоже, Unity нечуване час витрачає саме на підготовку сцени для демонстрації.

Результати тесту за критерієм «FPS»



Цей тест показав вельми цікаві результати в плані швидкодії. По-перше, показання FPS у девайсів PC і Galaxy однакові для обох движків. Ні Unity, ні Blend4Web тут особливо не виділилися. Цікаво, що динаміка FPS при зміні масштабу сцени у різних движків різнилася. Так, у Unity, найбільш високе значення виходило при видаленні камери від острова. Blend4Web видавав кращий результат, навпаки, при максимальному наближенні. Очевидно, движки використовують різні алгоритми оптимізації. Тому в таблиці вказані максимально можливі FPS в найбільш сприятливих ракурсах для движків.

Тепер щодо несподіваного крашу Apple iPad 3… Як ви бачите, до Nexus додався і цей девайс. На відміну від стандартно «лежачої» мотороллы, iPad чинив опір до останнього і злітав вже на самій сцені. Так що, заміряти завантаження вдалося, але, на жаль, працездатність програми Unity тут виявилася нульова.

Результати тесту за критерієм «Витрата пам'яті»



Перший тест показав практично однакову кількість споживаної пам'яті. Саме тут видно занадто велика різниця між роботою двох движків. Очевидно, Blend4Web зміг виконати внутрішню оптимізацію сцени, що не вийшло у Unity.

У сцені використовуються клоновані об'єкти і в ідеалі повинен був працювати инстансинг. Напевно, коригування певних параметрів може поліпшити результат, але движки поставлені в однакові умови і використовують одну і ту ж сцену, зроблену в Blender.

Дуже важкий тест, неоптимизированная сцена для WebGL, низькі FPS, але з двох движків повністю впорався тільки Blend4Web.

Тест №3. «Стрибаючі кульки»
Спочатку я думав зупинитися лише на двох сценах, але згадав про фізику. Так, так. Всіма нами улюблену фізику, коли об'єкти поводяться не так, як заплановано, провалюються крізь перешкоди, але без неї часто не обійтися.

Третій тест дуже простий, з точки зору використання GPU. Тут в основному «віддуватися» повинен процесор. Замкнутий простір куба, наповнене кількома десятками кульок. Об'єкт повільно обертається навколо осі, змушуючи тим самим кульки переміщатися, стикатися і падати.



З технічної сторони, фізика в сцені представлена простими коллайдерами (сфера, куб), rigid body, обертовий момент. Обидві сцени повністю ідентичні для тестованих движків, також однакові деякі фізичні параметри.

Як зазвичай, працездатність фізики в сцені вимагає певних зусиль. Ви, напевно, вже здогадалися, в чому проблема.

Кульки наполегливо прагнули залишити свою клітку і банально висипалися за її межі. Це стосувалося обох движків. В кінці-кінців було знайдено прийнятне якість роботи для платформи PC, коли всі об'єкти вели себе як заплановано, але ось на мобільних пристроях, ця сцена іноді виглядала дико. Тому був введений новий критерій тестування — стабільність фізики або, як я його назвав, — «кульки-аутсайдери». Сцена працювала протягом хвилини, а потім перевірялися об'єкти, що залишилися в клітці. Чим більше загубилося, тим гірше результат.

А тепер…

Результати тесту за критеріями «завантаження»





Результати тесту за критерієм «FPS»



Зверніть увагу на однакові показники FPS для сцени Blend4Web. Логічно припустити, що движок може видати набагато більше FPS, ніж 60, які обмежені вертикальною синхронізацією. Справа в тому, що Blend4Web вміє обробляти фізику окремому потоці (worker). Наскільки я знаю, Unity на це нездатна. Саме тут криється настільки високий FPS і, як ви далі побачите, хороші результати за критерієм «стабільність».

Результати тесту за критерієм «стабільність фізики»



Як і говорилося, Unity і Blend4Web дуже добре показали себе для платформи PC. Всі кульки залишилися на місці.

Серед мобільних пристроїв лідером виявився Galaxy S6 (Blend4Web), а аутсайдером став iPad 3 (Blend4Web). Додаток Unity за цим критерієм провалив тест, за винятком платформи PC.

Взагалі, від фізики Unity у WebGL залишилося дуже погане враження. Після завантаження сцени відбувалося гальмування екрану і лише через пару секунд набиралися настільки довгоочікувані FPS. Зрозуміло, це стосується лише PC, так як про мобільні девайси говорити абсолютно нічого — всі в таблиці.

Цілком імовірно, що відповідь на таке кричуще поведінка фізики у разі Unity криється в наступних результатах тесту пам'яті.

Результати тесту за критерієм «Витрата пам'яті»



Порівняно з першими двома, третя сцена виявилася самої ненажерливою за використання пам'яті. І це стосується обох движків.

Дуже дивним було поведінку додатка Unity. Після запуску сцени витрата пам'яті скакнув до 700 мб і лише через кілька секунд впав до 400. Ясна річ, що за цей час малопотужні мобільні девайси вже розгубили всі кульки. Тому дані FPS для цієї частини пристроїв невірні, бо крутився на екрані вже порожній куб без яких-небудь об'єктів.

Я не знаю, чим пояснити таку поведінку, але фізика в Unity WebGL показала себе не в кращому вигляді.

Висновки...
Висновки робити вам. Результати в статті, а внизу ви знайдете посилання на тестові програми, але я все ж додам пару слів від себе.

Були створені три різні сцени і тестувалися вони на найрізноманітніших пристроях, браузерах, системах. В більшості випадків результати Blend4Web були набагато краще, ніж у Unity. Це і правильно, адже Blend4Web створювався як фреймворк для створення додатків WebGL. Менше витрати пам'яті, спритна підготовка сцени до запуску, досить високий FPS незалежно від пристрою. Та й за рік фреймворк дуже покращився в плані інструментарію і можливостей. Значно зросла швидкодія.

Unity WebGL повністю розчарував. Повна непрацездатність на мобільних пристроях. Надзвичайно затягнутий запуск (навіть якщо виключити з часу демонстрацію заставки). Нестабільність фізики на слабких девайсів. І так, така ж повільна компіляція! Таке відчуття, що за рік движка розробники нічого толком не зробили і створили просту заглушку, придатну для самих простих сцен.

Посилання на тестові сцени:

» Тест №1. «Hello World!» (Unity)
» Тест №1. «Hello World!» (Blend4Web)

» Тест №2. «Важка артилерія» (Unity)
» Тест №2. «Важка артилерія» (Blend4Web)

» Тест №3. «Стрибаючі кульки» (Unity)
» Тест №3. «Стрибаючі кульки» (Blend4Web)

Увага! Посилання на тести додатків Unity працездатні, просто не видно завантажувач. Врахуйте, що завантаження у Unity йде набагато повільніше.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.