Pull to refresh

Comments 37

Спасибо за обзор. Интересный 3D engine c исходным кодом. Жаль только до Blender все никак не доберусь…
UFO just landed and posted this here
Парни из Unity сделали как раз версию для PPAPI давным-давно. Только интереса у разработчиков не было, так что из версии 4.3 поддержку убрали.

Собственно интереса и сейчас нет: на одного разработчика желающего замутить что-то такое в web'е приходится штук двадцать разработчиков под Android/iOS, так что понятно на что и почему тратят силы разработчики Unity.
У Unity маркетологи совершили свою главную ошибку — «перестарались» хвалить себя. Сколько демок WebGL у Unity не показывали — а первая половина просто не работает и вторая половина так долго загружается, что я и не знаю работает или нет. Если смотреть на веб глазами «мультиплатформенности» с дорогим мобильным интернетом и слабыми процами — юнити там не место и никогда места не будет. Тянуть 20 мегабайт движка ради коробки с 2мя текстурами — извольте.

Что касается нестабильности WebGL… еще 1.0 версия не работает толком, а они уже 2.0 изобретают.
У маркетологов работа такая. Разве маркетологи Flash или Unreal Engine ведут себя иначе?

Опять же Unity имеет смысл сравнивать только с другими универсальными движками, а не узкоспециализированными инструментами. Как обстоят дела с web у Unreal Engine?
Ибо изначальным преимуществом Unity над Flash были грязные хаки.


А разве не кроссплатформенность?
UFO just landed and posted this here
Только у меня сцена лагает и движения камеры/марсохода не плавные? (2.2 GHz Intel Core i7, AMD Radeon HD 6750M 1024 MB, Chrome)
Я не замечал. Запускал визуализацию на двух компах (chrome/ firefox). Вроде все нормально было.
Удивительно, но в Firefox у меня лагов нет (i7 4770, GTX 650ti cu2), а в Chrome еле тащит… Хотя, обычно, ситуация с точностью наоборот случается :)
У меня с Хром c 15-тью вкладками жесткими рывками только поворачивает. Что то я не понял где покупать боеприпасы и где база марсиан, которую надо разнести? Кто-нибудь уже сражался с боссом?
Вот она проблема универсальности, ну нельзя одним разводным ключом сделать космический корабль. А отсутствие у Unity WebGL, можно компенсировать остальными преимуществами. Ну а ребята из Blender4Web молодцы.
Кстати, на счет фразы автора «Причина — недостаточная производительность. Но у других-то движков звучит…» — всё дело в том, что WebGL для нормальной работы надо писать на ванильном JS, а не использовать для этого всякие компиляторы.
А вы уверены, что оптимизируете тяжелые вычисления лучше, чем это сделают современные с++ компиляторы? Потому как трансляция в asm.js сейчас очень близка к оптимальной.
Может обидно получиться, если за время, которое вы потратите на написание кода на ванильном JavaScript вместо использования компилятора, сменится пара поколений процессоров/устройств, что сведёт к нулю ваше преимущество в производительности, если таковое будет, а конкуренты успеют выпустить по два-три продукта.
Я с Вами согласен, что написать на ванильном будет сложно в одно лицо. Но не когда человек 20 в штате сидит. Это раз. Два — если крестовые компиляторы сделают это лучше — почему тогда мы видим дикие тормоза на выходе? Проблема в самом юнити получается? Я же хоть и не сторонник этого двигла, но ребята там всё же толковые сидят :) Видимо где-то есть стена, через которую не может пролезть компилятор.

Что касается производительности современных девайсов. Не стоит забывать, что основная масса владельцев моб. устройств меняют их не потому, что вышла более мощная модель. Именно по этой причине хоть завтра 5000 мгц выпустят девайс — аудитория, которая донатит в тех же играх не побежит за новым девайсом исключительно потому, что там юнити не будет в вебе тормозить. Им проще не выходить в тот веб будет ;)
UFO just landed and posted this here
соотв. делаем вывод — нам пытались втюхать кота в мешке
UFO just landed and posted this here
UFO just landed and posted this here
Я так понимаю, Unity обычно используют, когда делают многоплатформенный продукт, чтобы одним зайцем — и винду, и маки, и стим, и мобилы, и вот теперь ещё и веб :)
И в случае ванильного JS вам понадобятся эти 20 человек только для одной платформы.
Вполне допускаю, что в вашем случае это может быть оправдано, если вы, к примеру, делаете браузерку.

Ну и про мобильные устройства — что, кто-то действительно играет в браузерки на мобилах? Я, конечно, совершенно не в теме, но думал, что для мобил как раз делают отдельные приложения, так как это и без того слабые устройства, чтобы добавлять ещё тормозов в виде браузерной прослойки.
Мобилка — отдельная тема. Я это всем говорю, кто мне про смерть флеша рассказывает. Ведь можно флеш для браузера делать и тот же флеш — в виде отдельного приложения (Adobe AIR) для того же iOS/Android. Хвостом Desktop (Windows/MacOS). Но мне всегда доказывают все, что «а как же браузер в мобилке» :)

И тут я попадают в тупик. Одни говорят, что нафиг этот браузер, когда можно аппу из стора скачать (я это мнение разделяю) и другие мне доказывают, что «Как это браузер нафиг на мобил? Зачем тогда webgl придумали, канвас...»…
Веб-приложения — это ж замена десктопным приложениям, это я так вижу как разработчик веб-приложений :)
Выигрываем в универсальности, скорости обновлений, простоте доставки приложения к пользователю, проигрываем в производительности. Мощность современных десктопов нивелирует проигрыш в производительности для не самых требовательных приложений.
У мобильных приложений нет многих недостатков десктопных — установка из централизованного репозитория не намного сложнее веб-приложения, обновления централизованы и часто выполняются автоматически, но проигрыш в производительности веб-приложения на мобильном устройстве нативному пока слишком велик, как мне кажется.
То есть по сути почти все проблемы десктопных приложений сводятся к отсутствию нормального репозитория/магазина приложений и нормальной системы обновлений (обычно являющейся частью такого магазина).

Спасибо Microsoft, что еще можно сказать. Я не вижу никаких технических причин, которые мешали бы сделать нормальный магазин для десктопных приложений еще для Windows 7 (ну как минимум с поддержкой, добавляемой в сервис-паке).
Смотрю на вас с ubuntu и не понимаю, что microsoftу мешало это лет 10 назад скопировать…
У Microsoft была другая политика и именно благодаря ей они выехали. Её смысл прост — ставь любой софт (купленный или украденный). Главное не кради сам Windows, а его покупай.

Если бы сразу они заставляли покупать, а не пиратить — % виндопользователей был бы существенно ниже.
у веб-апп возникают проблемы когда нет интернета на девайсе, а поиграть/посмотреть карту хочется, например. Дальше, функциональность — поправьте если не прав, у нативных апп больше возможностей работы с самой осью (работа с файлами, настройками етс..)
Да, конечно, антивирус или программу для разбиения дисков не сделаешь в браузере, но для сетевых игр и разных баз данных, в том числе карт — ок.
WebGL… Есть у меня задачка на WebGL. Возможно скоро выложу в публичный доступ.

Так вот, тесты показали, что WebGL очень сильно зависит от производительности CPU. То, что хорошо работает на десктопе — на WebGL будет тормозить на одном и том же железе.

При этом под виндой есть еще такая приблуда ANGLE. Если её отключить — я получал 2 мс на отрисовку кадра, что нормально при том железе, на котором я тестировал. Но включенным ANGLE — у меня получалось порядка 60-70 мс на отрисовку.

Я не использовал никаких движков, все на чистых WebGL командах. Поэтому я пока делаю такой вывод: задумка — хорошая, но для игр ААА класса — реализация слишком медленная. Не будешь ведь ты заставлять всех пользователей насильно отключать какую-то опцию в браузере, вияющую на безопасность только для того, чтобы поиграть в твою игру\посмотреть демо
Обращаю внимание хабраюзеров на качество данной статьи. Это не перевод, не коллекция ссылок или фоток очередной железки, не перепечатка или пересказ новостей. Это оригинальные мысли автора, изложенные неплохим языком, и орфография проверена. Я, конечно, говорю банальности, но сейчас это редкость. Таких авторов нужно всячески поддерживать.
А самое главное — есть конструктивное «за» и «против». А то уже устал читать о том, как юнити превозносят в лики святых. Хороший маркетинг — хорошо. Но его переизбыток — плохо.
Хотел бы еще задать вопрос знающим тонкости…

Автор упомянул, что в юнити ждут OpenGL 3.0. Но у меня вопрос иного рода. Чем отличается по производительности 3.0 от 2.0? Из того, что я читал по интернетам (а 3.0 ведь с августа 2012 в релизе) — там не нарост производительности, а увеличение полюшек для качества визуала. Но и требования к видеокартам повыше становятся, чтоб они «смогли это скушать». Получается, что снова те же грабли будут, но в уже WebGL 2.0, раз они думают, что новые форматы текстур смогут ускорить обмен данных между браузером, вирт. машиной js и видеокартой с процессором.

В общем… у меня много вопросов. Такое ощущение, что они (маркетологи) пишут что попало, лишь бы в гугле чаще слово юнити выпадало. К автору не имеет отношения — не первый раз про это слышу.
OpenGL — это такое болото, в котором нужно долго разбираться, чтобы понять всю глубину наших глубин :)

По порядку.

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)
С js — все в порядке (да, векторные/матричные операции без simd медленные, но asmjs решает проблемы с производительностью). В итоге разница по скорости — примерно в 2 раза по сравнению с C++.

Главная проблема WebGL1.0 — это работа с текстурами. Текстуры требуется отправлять перепаковывать для GPU, это занимает время и требует много памяти. Сейчас по моему это делается вообще в 1 поток. Кроме того asmjs сам по себе требует память и времени на компиляцию.

С WebGL2.0 и wasm эти проблемы должны решиться. Касательно Unity, пока идеальный вариант — использовать его как редактор и экспортировать сцену в BABYLON.JS (экспортер пока слабенький, но руками довести до ума можно). А логику при этом писать на чистом js с asm оптимизацией (там где это необходимо). С простыми сценами вообще говоря и Unity WebGL справляется весьма сносно (нужно учитывать его огрехи, к примеру тени импортируются криво и нужно создавать костыли, чтобы это пофиксить).
В статье сравниваются совершенно разные вещи — универсальный, кросс-платформенный Unity и узкоспециализированный Blend4Web который ничего кроме Web не поддерживает?

На Blend4Web можно писать под мобильные платформы, приставки, десктоп? Насколько я понял нет.

В таком случае неудивительно, что универсальный многоцелевой инструмент в одной из областей проигрывает узкоспециализированному инструменту, жестко заточенному под решений только одной задачи.

Это же абсолютно естественно, что в этом такого удивительного?
Разве в статье есть какое-то сравнение между движками? Лейттема — проблемы Unity с платформой веб.
Sign up to leave a comment.

Articles