Pull to refresh

Comments 37

Зря Unity WebGL вывели из бетты, стабильности ведь 0, просто непригодно для производства. Морочат своему сообществу голову, которое бесполезно тратит своё время на попытки делать проекты на Unity WebGL. Они ведь ничему новому не научатся, процесс создания тот же, что и для других платформ. И для чего всё это тогда? Привлечь новых разработчиков, которым нужен WebGL и разочаровать их? По-моему, Unity этой поделкой только дискредитирует сам WebGL.

Пара вопросов:


  1. Сколько весили сцены?
  2. Сколько шариков в сцене «Прыгающие мячики?

Мои результаты на Redmi Note 3:




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




Тест №2. «Тяжелая артиллерия» (Unity) — 3 fps
Тест №2. «Тяжелая артиллерия» (Blend4Web) — 9 fps




Тест №3. «Прыгающие мячики» (Unity) — 40 fps — осталось ровно 5 мячей
Тест №3. «Прыгающие мячики» (Blend4Web) — 60 fps — выпало около 10 мячей

Шариков около 60.

Тест№2 очень тяжелый для мобильных и, конечно, так делать сцену не следовало. Но мне было все же интересно, а вытянут ли? :)

Скорее всего по тесту 3 Blend4Web показал бы лучший результат (если бы удалось отключить синхронизацию). Физика в отдельном потоке рулит.
Приятно удивлён производительностью blend4web. Если бы ещё было разрабатывать так же удобно как Unity. И да, в Unity3d WebGL ещё совсем сырой. Падает из-за слишком длительных непрерывных вычислений, падает из-за слишком большого потребления памяти(>512 мб).

Вы могли бы поделиться исходниками проектов?
Какой вам интересен? Фишка в том, что в одном из них закрытый контент…
Ок. Завтра выложу. Проекты остались на работе.
Выложил. Ссылка в конце статьи.

Ну ОК, Unity WebGL, скажем, пока не очень. Но ведь на телефонах он может и Vulkan/Metal использовать. А что сможет этому противопоставить Blend4Web?

Vulkan/Metal использовать

А зачем? Лучше сделать нормальное веб-приложение, которое будет работать везде и не уступать по функционалу и удобству использования нативным. Преимущества WebGL очевидны.

По скорости WebGL никогда не будет дотягивать до Vulkan/Metal.

Не надо сравнивать веб и приложения. Допустим, на сайте нужен 3D конструктор, заходит случайный пользователь из гугла, а вы ему тут же «установи приложение», оно ему надо?
webAssembly ждемс… а там уже потанцуем с Vulkan/Metal… в плане производительности
Самим интересно, будет ли наша физика быстрее работать. Начет вулкана не уверен, соответствующего веб-стандарта на горизонте не просматривается.
если эт про Vulkan https://en.wikipedia.org/wiki/Vulkan_(API)… то тут вроде даже не корректное сравнение, сравнивать WebGL — как платформу запуска игры в браузере, и API низкого уровня для работы с GPU… я что то подумал есть нейкий конкурент Vulkan — типо Unity Web Player… кстати насчет вулкана
Unity – The engine will support Vulkan in an early state in Q3 2016
i5-6500 CPU @ 3.20GHz × 4 (со встроенной графикой), и 8гб оперативы.
Ubuntu 16.04
Chrome 53.0.2785.101 (64-bit)
На Unity 2й тест грузился порядка минуты, при этом выглядел очень вырвиглазно по сравнению с Blend4Web.
С остальными тестами в принципе аналогично, загрузка Unity в разы дольше, по фпс / потреблению памяти могу сделать замеры если нужно.
Three.js я не использую. Поэтому не в курсе, что там с ним творится. Хотя, да, вопрос интересный.
Какие шейдеры использовались в сборке Unity?
standard. Возможно было бы лучше использовать мобильный bumped diffuse или из legacy аналогичный, но unity предлагает по умолчанию именно standard
стандартный шейдер универсальный, так же как и сам Unity) думаю нету пока что нечего удивительно, что универсальный движок проигрывает узконаправленным… Если использовать мобильный шейдер, и тест проводить на мобилах fps двух кратно может подскачить (Standart shader — тяжеловат для мобил)
Если не ошибаюсь, Standard использует физически корректный шейдинг, что сложнее прорисовать. Legacy было бы использовать рациональней
Я уже год не прикасался к treejs и знаю его не столь хорошо, как unity и blend4web. Но, это может быть интересно. Подумаю. Можно попытаться перенести эти же тестовые сцены, тогда получится тройное перекрестное тестирование.

Ну, это будет сложно сделать, на сколько я понимаю. Ведь что unity что blend4web это не только движки но и редакторы сцен, официально поддерживаемые редакторы, где есть понятие дефолтных настроек и в целом схожий подход к созданию сцен. В three.js этого нет.
Но вообще я бы посмотрел сравнение three.js и blend4web. Но меня больше интересует не производительность, а сколько времени уйдёт на создание одинаковой демо сцены с разными движками. Предполагаю что three.js значительно проиграл бы в этом.

Скорее делают чем сделали, есть ведь и аддоны для того же блендера, они тоже в какой то степени делают редактор для three.js из блендера, но всё это пока в процессе.

Как по мне тесты проводились по принципу взять и запустить, но без должных знаний и навыков работы с двумя сравниваемыми продуктами, без понимания внутренних механизмов обоих, без должной проделанной работы по оптимизациям в каждом из тестов можно считать их не валидными. Хотелось бы увидеть валидные тесты по всем пунктам проведения тестов.
Не согласен. Движки были поставлены в одинаковые условия: одни и те же модели, текстуры, расположение и типы источников света, разрешение экрана, типы материалов, антиалиасинг и многое другое. Я соглашусь с тем, что можно было бы выполнить оптимизацию, как с Unity, так и с Blend4Web. В этом случае результат стал бы более качественным, но относительные значения, скорее всего, остались бы такими же. Задача была не «вылизать» сцены для обоих движков, а работать с тем, что есть по умолчанию.Так, например для третьего теста, сцена оптимизировалась для физики, но это делалось параллельно для обеих платформ. В другом случае, unity немного лучше себя вела при использовании legacy-шейдеров, но это не выбор по умолчанию и т.д. и т.п.
Простите, но мне как человеку долго и тесно работающего с Unity3D это всё кажется весьма странно…
Мне, как человеку долго работающему с Unity3d, ничего тут не кажется странным. Особенно долго работал с WebGl. Под выводами автора поста могу подписаться. А т.к. c 3D в вебе я работаю ещё дольше чем с Unity3d, то догадываюсь почему всё так вышло.
Надо ещё vs PlayCanvas, он по-моему круче чем Blend4Web. three.js в данном случае далеко не показатель, хрен сцену сделаешь там, но из этого класса движков можно использовать Babylon.js

Сравнение любое интересно, кто бы сделал :). Но вот на счёт крутости процесса создания сцен не уверен что PlayCanvas круче. Там же облачный редактор, в редакторе сцена неподготовленная, мне кажется должно лагать при работе со сложными сценами.
Babylon.js это движок такого же типа что и three.js.

В playcanvas есть тулзы для запекания света, а для threejs и babylon да, придется поизвращаться.
На случай если кто не видел никогда asm.js
image
ну и так десятки мегабайт…
Такие движки как юнити или унриал используют технологию emscripten, — транслируют C++ в asm.js работает такой код действительно быстро, но глючный и весит много, — совершенно не приспособлен для использования. У анриал поддержка webGL помечена как эксперементальная, у юнити не знаю.
Вполне закономерные результаты у blend4web, раз они напрямую работают с webGL из js.
Sign up to leave a comment.

Articles