Еще два года назад (или даже больше) были публикации о создании подобной сцены для NASA на Unity. Однако, дальше беты дело не продвинулось и космическое агентство отказалось от использования Unity. Интересны причины, побудившие программистов столь крупной организации забросить начатое дело и начать работу с нуля. Я не поленился и нашел в сети Интернет упомянутую бета-версию «марсохода». Честно говоря, похоже на недоделанную игру. Медленно загружается сцена (еще дольше грузится terrain), функциональность — только покататься, картинка ужасающая.
Но мы то знаем, что на Unity делаются потрясающие игры, а портфолио забито сотнями качественных проектов. Так в чем же дело?
Версия на Unity
Дело в том, что Unity серьезно опаздывает с окончательным выходом экспортера в WebGL. Первый сигнал прозвучал, когда создатели Google Chrome объявили о грядущем отказе от NPAPI. Процент пользователей в мире, работающих с этим браузером, слишком велик, чтобы разработчики программ могли оставить их «за бортом». В сети Интернет появились советы использовать волшебную команду chrome://flags/#enable-npapi. Однако в сентябре 2015 года будет прикрыта и эта лазейка.
Создание игр или презентаций для сайтов — это бизнес. Никто не любит терять своих клиентов. И если ранее скачивание веб-плеера Unity не доставляло хлопот и он успешно конкурировал с flash-технологией, то сейчас ситуация в корне изменилась. Привычный веб-плеер стремительно теряет свои позиции, а экспортер в WebGL все еще в «детском» возрасте.
Разработчики всех мастей поднимали шум, требуя от команды Unity каких-то активных действий. И вот случилось долгожданное событие — выход Unity 5 с WebGL, но только, как превью. Прошло полгода, а воз и поныне там. Появилось даже «гениальное» предложение проверять браузер пользователя и предлагать ему запускать веб-плеер в каком-нибудь другом. К сожалению, это по понятным причинам, не всегда приемлемо.
И все же, что происходит у Unity с WebGL? Почему не выходит стабильная версия? Какие перспективы? Эти вопросы интересны многим разработчикам. Я не технарь и мне сложно понять проблемы Unity в этой области, но кое-что найденное в сети Интернет, навевает на грустные размышления.
На официальном форуме Unity есть тред, который называется «WebGL Roadmap». Официальное лицо от команды разработчиков дает разъяснения по поводу будущего WebGL в Unity. Я просматривал вдоль и поперек этот текст, и все больше убеждался, что “светлое будущее“ еще только на горизонте.
WebGL по умолчанию должна работать на браузерах для всех платформ, включая и мобильные. Этого нет. И если каким-то чудом вы скомпилируете в WebGL свою игру, то вычеркивайте мобильные устройства из списка. Причины банальны — катастрофически большой расход памяти и низкая производительность. Да, игра запустится на топовом устройстве с терпимой скоростью, но более слабые превратятся в черепах.
И не надейтесь, что проект спокойно заработает на десктопных системах. Браузеры — это программы, которые просто пожирают свободную память компьютера и сырой билд от Unity зачастую приводит к падению или закрытию вкладок. Особо этим грешит Chrome.
Есть определенные проблемы со звуком. Лично я, когда пробовал экспортировать несложную игру под WebGL, при движениях героя получал какое-то кваканье. Звук банально заедал и исправить это толком не удалось. Причина — недостаточная производительность. Но у других-то движков звучит…
Забудьте о проигрывании видео в игре. Класс MovieTexture просто не поддерживается для WebGL, В виде альтернативы разработчики предлагают использовать напрямую возможности HTML5.
Проблемы с сетью. Классы System.IO.Sockets и UnityEngine.Network не работают для WebGl и не будут в дальнейшем, так как это вызывает проблемы с безопасностью.
Я перечислил не все проблемы, но это не дает ответа на вопрос, когда заработает? Увы, комментарии разработчиков Unity невнятны, туманны и без каких-либо конкретных сроков. Хотя кое-что я нашел:
«We are not committing to specific release dates for any of these features, and we may decide not to go ahead with some of these at all».
«Мы не фиксируем конкретные даты реализации для любой из этих функций и мы можем вообще принять решение отказаться от некоторых».
Они ждут…
Ждут, когда появится WebGL 2.0, который будет базироваться на OpenGL ES 3.0. Будущая версия Unity 5.2 уже запланирована с возможностью экспорта под новый API. Только не факт, что браузеры сразу начнут полноценно работать с ним. Пока WebGL2.0 доступен, как экспериментальная опция.
Ждут WebAssembly, который очень перспективный, но еще на этапе становления. Разговора о сроках его реализации и в помине нет.
Простите, если дело исправит только выход новых сторонних технологий, то, возможно, проблема в реализации Unity WebGL?
Unity — это удобный, популярный и кроссплатформенный движок. Отличный инструмент для создания игр и мне он очень нравится. Но все же это инструмент, который перестал годится для работы с веб. Cамое неприятное, что будущее слишком туманно.
Кто-то может мне сказать: «Ты пессимист!». Нет, я просто реалист. Реалисты и ребята из NASA. По сути, это дает ответ на вопрос из названия: «Почему в NASA отказались от Unity в пользу Blend4Web?».
Отказались по простой причине — Unity WebGL не готов, а когда будет?
«We are not committing to specific release dates...»
А что же с Blend4Web? Я могу только поздравить разработчиков с явно убедительной победой на поприще WebGL и порадоваться за наших программистов, ведь презентация NASA, сделанная на b4w будет показана при открытии секции WebGL на SIGGRAPH 2015. И это уже признание.
Комментарии (37)
fzn7
10.08.2015 12:55Ибо изначальным преимуществом Unity над Flash были грязные хаки. Еще в 2014м Гугл предупреждал и Adobe и Unity о грядущем отключении NPAPI. Результатом для флеша стал тяжелый и долгий переход на PepperFlash версию с бесконечным поливанием технологии грязью. А парни из Unity решили просто устроить еще красивых конференций. Единственное спасение — экспорт в WebGL, нестабильную платформу, которая по состоянию на 2015 год так и предоставила нам рай HTML5, о котором все так долго говорят.
khim
10.08.2015 13:22+2Парни из Unity сделали как раз версию для PPAPI давным-давно. Только интереса у разработчиков не было, так что из версии 4.3 поддержку убрали.
Собственно интереса и сейчас нет: на одного разработчика желающего замутить что-то такое в web'е приходится штук двадцать разработчиков под Android/iOS, так что понятно на что и почему тратят силы разработчики Unity.
TheRabbitFlash
10.08.2015 13:48-2У Unity маркетологи совершили свою главную ошибку — «перестарались» хвалить себя. Сколько демок WebGL у Unity не показывали — а первая половина просто не работает и вторая половина так долго загружается, что я и не знаю работает или нет. Если смотреть на веб глазами «мультиплатформенности» с дорогим мобильным интернетом и слабыми процами — юнити там не место и никогда места не будет. Тянуть 20 мегабайт движка ради коробки с 2мя текстурами — извольте.
Что касается нестабильности WebGL… еще 1.0 версия не работает толком, а они уже 2.0 изобретают.
Vedomir
11.08.2015 09:17У маркетологов работа такая. Разве маркетологи Flash или Unreal Engine ведут себя иначе?
Опять же Unity имеет смысл сравнивать только с другими универсальными движками, а не узкоспециализированными инструментами. Как обстоят дела с web у Unreal Engine?
kozyabka
10.08.2015 12:57+2Только у меня сцена лагает и движения камеры/марсохода не плавные? (2.2 GHz Intel Core i7, AMD Radeon HD 6750M 1024 MB, Chrome)
Prand
10.08.2015 13:05Я не замечал. Запускал визуализацию на двух компах (chrome/ firefox). Вроде все нормально было.
TheRabbitFlash
10.08.2015 13:55-1Удивительно, но в Firefox у меня лагов нет (i7 4770, GTX 650ti cu2), а в Chrome еле тащит… Хотя, обычно, ситуация с точностью наоборот случается :)
deep_orange
11.08.2015 13:47+2У меня с Хром c 15-тью вкладками жесткими рывками только поворачивает. Что то я не понял где покупать боеприпасы и где база марсиан, которую надо разнести? Кто-нибудь уже сражался с боссом?
MKutuzoff
10.08.2015 13:25+6Вот она проблема универсальности, ну нельзя одним разводным ключом сделать космический корабль. А отсутствие у Unity WebGL, можно компенсировать остальными преимуществами. Ну а ребята из Blender4Web молодцы.
TheRabbitFlash
10.08.2015 14:07+3Кстати, на счет фразы автора «Причина — недостаточная производительность. Но у других-то движков звучит…» — всё дело в том, что WebGL для нормальной работы надо писать на ванильном JS, а не использовать для этого всякие компиляторы.
YoungSkipper
10.08.2015 14:54+4А вы уверены, что оптимизируете тяжелые вычисления лучше, чем это сделают современные с++ компиляторы? Потому как трансляция в asm.js сейчас очень близка к оптимальной.
Goodkat
10.08.2015 15:13-1Может обидно получиться, если за время, которое вы потратите на написание кода на ванильном JavaScript вместо использования компилятора, сменится пара поколений процессоров/устройств, что сведёт к нулю ваше преимущество в производительности, если таковое будет, а конкуренты успеют выпустить по два-три продукта.
TheRabbitFlash
10.08.2015 15:23-1Я с Вами согласен, что написать на ванильном будет сложно в одно лицо. Но не когда человек 20 в штате сидит. Это раз. Два — если крестовые компиляторы сделают это лучше — почему тогда мы видим дикие тормоза на выходе? Проблема в самом юнити получается? Я же хоть и не сторонник этого двигла, но ребята там всё же толковые сидят :) Видимо где-то есть стена, через которую не может пролезть компилятор.
Что касается производительности современных девайсов. Не стоит забывать, что основная масса владельцев моб. устройств меняют их не потому, что вышла более мощная модель. Именно по этой причине хоть завтра 5000 мгц выпустят девайс — аудитория, которая донатит в тех же играх не побежит за новым девайсом исключительно потому, что там юнити не будет в вебе тормозить. Им проще не выходить в тот веб будет ;)fzn7
10.08.2015 15:27Дикие тормоза мы видим, т.к. нам надо не только перевести код в кучку красивых опкодов, а в первую очередь нам нужна быстрая работа с памятью. Если виртуальная машина врубает GC когда ей этого хочется, оборачивает данные в обертки, вычисляет тип данных на ходу, то падение производительности в 30 раз не является чем-то удивительным.
TheRabbitFlash
10.08.2015 15:35соотв. делаем вывод — нам пытались втюхать кота в мешке
fzn7
10.08.2015 15:44Этот кот в мешке (asm.js) наверняка является братом близнецом AVM2, аз есмь канувший в лету Tamarin Tracing, который Adobe пилил в сотрудничестве с Mozilla. В итоге получается интересная история. Мы смотрим на одно и тоже решение в разных обертках, без реальных конкурентных преимуществ. Война ведется маркетингом и победит тот у кого рупор громче. Все остальное — пыль в глаза.
igor_suhorukov
10.08.2015 15:57asm.js не выделяет память в куче
Much of this performance gain over normal JavaScript is due to 100% type consistency and virtually no garbage collection (memory is manually managed in a large typed array)fzn7
10.08.2015 16:13Они все это умеют, но все между собой несовместимы. FireFox через asm.js + OdinMonkey, Chrome через NaCL, Flash через domainMemory API и все тянут одеяло на себя.
Goodkat
10.08.2015 16:06+2Я так понимаю, Unity обычно используют, когда делают многоплатформенный продукт, чтобы одним зайцем — и винду, и маки, и стим, и мобилы, и вот теперь ещё и веб :)
И в случае ванильного JS вам понадобятся эти 20 человек только для одной платформы.
Вполне допускаю, что в вашем случае это может быть оправдано, если вы, к примеру, делаете браузерку.
Ну и про мобильные устройства — что, кто-то действительно играет в браузерки на мобилах? Я, конечно, совершенно не в теме, но думал, что для мобил как раз делают отдельные приложения, так как это и без того слабые устройства, чтобы добавлять ещё тормозов в виде браузерной прослойки.TheRabbitFlash
10.08.2015 16:56Мобилка — отдельная тема. Я это всем говорю, кто мне про смерть флеша рассказывает. Ведь можно флеш для браузера делать и тот же флеш — в виде отдельного приложения (Adobe AIR) для того же iOS/Android. Хвостом Desktop (Windows/MacOS). Но мне всегда доказывают все, что «а как же браузер в мобилке» :)
И тут я попадают в тупик. Одни говорят, что нафиг этот браузер, когда можно аппу из стора скачать (я это мнение разделяю) и другие мне доказывают, что «Как это браузер нафиг на мобил? Зачем тогда webgl придумали, канвас...»…Goodkat
10.08.2015 17:17Веб-приложения — это ж замена десктопным приложениям, это я так вижу как разработчик веб-приложений :)
Выигрываем в универсальности, скорости обновлений, простоте доставки приложения к пользователю, проигрываем в производительности. Мощность современных десктопов нивелирует проигрыш в производительности для не самых требовательных приложений.
У мобильных приложений нет многих недостатков десктопных — установка из централизованного репозитория не намного сложнее веб-приложения, обновления централизованы и часто выполняются автоматически, но проигрыш в производительности веб-приложения на мобильном устройстве нативному пока слишком велик, как мне кажется.Vedomir
11.08.2015 09:07То есть по сути почти все проблемы десктопных приложений сводятся к отсутствию нормального репозитория/магазина приложений и нормальной системы обновлений (обычно являющейся частью такого магазина).
Спасибо Microsoft, что еще можно сказать. Я не вижу никаких технических причин, которые мешали бы сделать нормальный магазин для десктопных приложений еще для Windows 7 (ну как минимум с поддержкой, добавляемой в сервис-паке).
mickvav
12.08.2015 17:53Смотрю на вас с ubuntu и не понимаю, что microsoftу мешало это лет 10 назад скопировать…
TheRabbitFlash
12.08.2015 18:22У Microsoft была другая политика и именно благодаря ей они выехали. Её смысл прост — ставь любой софт (купленный или украденный). Главное не кради сам Windows, а его покупай.
Если бы сразу они заставляли покупать, а не пиратить — % виндопользователей был бы существенно ниже.
kozyabka
11.08.2015 09:12у веб-апп возникают проблемы когда нет интернета на девайсе, а поиграть/посмотреть карту хочется, например. Дальше, функциональность — поправьте если не прав, у нативных апп больше возможностей работы с самой осью (работа с файлами, настройками етс..)
Goodkat
11.08.2015 09:20Да, конечно, антивирус или программу для разбиения дисков не сделаешь в браузере, но для сетевых игр и разных баз данных, в том числе карт — ок.
Deamon87
10.08.2015 17:14+1WebGL… Есть у меня задачка на WebGL. Возможно скоро выложу в публичный доступ.
Так вот, тесты показали, что WebGL очень сильно зависит от производительности CPU. То, что хорошо работает на десктопе — на WebGL будет тормозить на одном и том же железе.
При этом под виндой есть еще такая приблуда ANGLE. Если её отключить — я получал 2 мс на отрисовку кадра, что нормально при том железе, на котором я тестировал. Но включенным ANGLE — у меня получалось порядка 60-70 мс на отрисовку.
Я не использовал никаких движков, все на чистых WebGL командах. Поэтому я пока делаю такой вывод: задумка — хорошая, но для игр ААА класса — реализация слишком медленная. Не будешь ведь ты заставлять всех пользователей насильно отключать какую-то опцию в браузере, вияющую на безопасность только для того, чтобы поиграть в твою игру\посмотреть демо
ComodoHacker
10.08.2015 20:27+7Обращаю внимание хабраюзеров на качество данной статьи. Это не перевод, не коллекция ссылок или фоток очередной железки, не перепечатка или пересказ новостей. Это оригинальные мысли автора, изложенные неплохим языком, и орфография проверена. Я, конечно, говорю банальности, но сейчас это редкость. Таких авторов нужно всячески поддерживать.
TheRabbitFlash
10.08.2015 23:40А самое главное — есть конструктивное «за» и «против». А то уже устал читать о том, как юнити превозносят в лики святых. Хороший маркетинг — хорошо. Но его переизбыток — плохо.
TheRabbitFlash
10.08.2015 23:55-1Хотел бы еще задать вопрос знающим тонкости…
Автор упомянул, что в юнити ждут OpenGL 3.0. Но у меня вопрос иного рода. Чем отличается по производительности 3.0 от 2.0? Из того, что я читал по интернетам (а 3.0 ведь с августа 2012 в релизе) — там не нарост производительности, а увеличение полюшек для качества визуала. Но и требования к видеокартам повыше становятся, чтоб они «смогли это скушать». Получается, что снова те же грабли будут, но в уже WebGL 2.0, раз они думают, что новые форматы текстур смогут ускорить обмен данных между браузером, вирт. машиной js и видеокартой с процессором.
В общем… у меня много вопросов. Такое ощущение, что они (маркетологи) пишут что попало, лишь бы в гугле чаще слово юнити выпадало. К автору не имеет отношения — не первый раз про это слышу.Deamon87
11.08.2015 01:32+10OpenGL — это такое болото, в котором нужно долго разбираться, чтобы понять всю глубину наших глубин :)
По порядку.
1) Есть GPU, что есть железо. GPU бывают разные. OpenGL\DirectX — это некоторая API прослойка, которая ненапрямую дергает фукнции, реализованные в железе. За трансляцию вызовов OpenGL\DirectX в вызовы функций железа отвечает драйвер GPU, который поставляется вендором GPU.
2) Начиная с 1.0, OpenGL строился на основе расширений. Расширения предлагались в Khronos group. Последовательность повышения ранга: вендерские -> arb -> core. Вендерские реализуются только определенным вендером, например ATI или Nvidia. Когда в очередной версии расширение объявляется core, то это значит, что все GPU, у которых заявлено о поддержки данной версии OpenGL — обязаны реализовать этот фукнционал у себя (и желательно в железе, а не на уровне драйверов). Также расширение может стать EXT. Тогда оно остается опциональным и необязательно для реализации.
3) Основная особенность OpenGL 3.0 от 2.0 — это устаревание части функций API. До 3.0 ни одна функция не объявлялась устаревшей. Как, пример устаревших фукнций: стеки матриц. В 2.0 были функции glPushMatrix\glPopMatrix. В 3.0 они уже считаются устаревшими и их поведение нужно реализовывать самому(не вдаваясь в тонкости — самому более красиво получается с точки зрения архитектуры графич. движка). И если в 2.0. можно было рисовать без использования шейдеров, то в 3.0 шейдер обязательно должен быть. Нету шейдера — не тру 3.0( обратную совместимость все таки оставили). И попутно в 3.0 конечно добавили новых расширений.
4) Далее по WebGL. WebGL 1.0. делался на основе спецификации OpenGL ES 2.0, которая в свою очередь делалась на основе OpenGL 2.0. Таким образом те расширения, которые введены в core в OpenGL 3.0, в WebGL изначально отсутствуют. Но при этом есть и свои отличия.
В WebGL 1.0 изначально заложено требование о существовании шейдера. Без шейдера ты ничего не отрисуешь. И те фукнции, которые были объявлены устаревшими в OpenGL 3.0 — тут отсутствуют на корню. Поэтому это такой некий симбиоз функциональности OpenGL 2.0 и изменений, внесенных в OpenGL 3.0.
5) Для чего нужен WebGL 2.0? Нужен он чтобы сделать доступными для браузера те расширения\плюшки, которые есть в OpenGL ES 3.0\OpenGL 3.2&4.2 и без которых некоторые графические эффекты невозможно воспроизвести. Но так же это означает, что не все мобильные GPU смогут исполнить такую программу.
6) По форматам текстур. Есть такое расширение в WebGL 1.0: WEBGL_compressed_texture_s3tc. Если оно доступно — то видеокарта может использовать сжатые текстуры в форматах DXT1, DXT3 и DXT5. А это именно тот поток данных, который будет передаваться на GPU. Но это расширение не поддерживается почти всеми мобильными GPU.
Для мобильных же существует WEBGL_compressed_texture_pvrtc. Эти форматы сжатия поддерживаются многими мобильными GPU, но при этом _не поддерживаются_ настольными.
То, что в WebGL 2.0 вводят новые форматы сжатия для текстур — это хорошо, но координальных проблем не решает. Для того, чтобы получить от этого выигрыш, производителям игрушек\3D конента нужно будет предварительно сжимать свои текстуры в этот формат.
И чисто мое имхо: главная проблема производительности WEBGL сейчас — это медленная виртуальная машина js(большая зависимость от производительности CPU)Large
17.09.2015 22:42-1С js — все в порядке (да, векторные/матричные операции без simd медленные, но asmjs решает проблемы с производительностью). В итоге разница по скорости — примерно в 2 раза по сравнению с C++.
Главная проблема WebGL1.0 — это работа с текстурами. Текстуры требуется отправлять перепаковывать для GPU, это занимает время и требует много памяти. Сейчас по моему это делается вообще в 1 поток. Кроме того asmjs сам по себе требует память и времени на компиляцию.
С WebGL2.0 и wasm эти проблемы должны решиться. Касательно Unity, пока идеальный вариант — использовать его как редактор и экспортировать сцену в BABYLON.JS (экспортер пока слабенький, но руками довести до ума можно). А логику при этом писать на чистом js с asm оптимизацией (там где это необходимо). С простыми сценами вообще говоря и Unity WebGL справляется весьма сносно (нужно учитывать его огрехи, к примеру тени импортируются криво и нужно создавать костыли, чтобы это пофиксить).
Vedomir
11.08.2015 09:13В статье сравниваются совершенно разные вещи — универсальный, кросс-платформенный Unity и узкоспециализированный Blend4Web который ничего кроме Web не поддерживает?
На Blend4Web можно писать под мобильные платформы, приставки, десктоп? Насколько я понял нет.
В таком случае неудивительно, что универсальный многоцелевой инструмент в одной из областей проигрывает узкоспециализированному инструменту, жестко заточенному под решений только одной задачи.
Это же абсолютно естественно, что в этом такого удивительного?
Prand
11.08.2015 09:32+2Разве в статье есть какое-то сравнение между движками? Лейттема — проблемы Unity с платформой веб.
igor_suhorukov
Спасибо за обзор. Интересный 3D engine c исходным кодом. Жаль только до Blender все никак не доберусь…