Обновить
10
0
Yuri Karadzhov@Large

Пользователь

Отправить сообщение
почему-то подход с символами не работает вместе с анимациями в хроме (на айпаде работает). Если символ заменить на группу, то проблема исчезает.
С js — все в порядке (да, векторные/матричные операции без simd медленные, но asmjs решает проблемы с производительностью). В итоге разница по скорости — примерно в 2 раза по сравнению с C++.

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

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

Падающие браузерные вкладки говорят о проблемах с вашей сборкой, что-то не доготовили, что-то не оптимизировали или не выключили. Веб есамбли не коректо сравнивать с PPAPI, и к веб разработке он не имеет никакого отношения. Более того все современные движки уже умеют работать с asmjs так что веб есамбли будет внедрен естественным образом.

Да, это не правильная ссылка, но я точно видел асасин крид на одной из юнити демок про веб. В любом случае демок хватает — их показывают на юнайт и других юнити встречах.

Блендер довольно широко распространен, просто не все компании с ним работают. Майя — стандарт де факто многие вспомогательные инструменты разрабатывают именно под майю. Пиратство тут не при чем, просто полный цикл становится удобнее и переучивать людей никто не хочет.

Да, благодаря веб есамбли доставка мультимедийного контента через веб упростится и многие тяжелые игры станут доступны прямо из браузера. Юнити плагин продолжает работать везде кроме хрома и хромиума, так что о его пенсии говорить рано.
Посмотрите в юнити блоге. По поводу поддержки — скорей всего вы используете скрипты деплоя предложенные юнити, а не свои. Их скрипты ругаются на ИЕ10 и Опреа. При том в опере все работает как есть, а в ие10 нет аудио апи потому работает без звука.

Проблемы конечно есть, движок сыроват, несравнимо проще деплоить под вебплеер. Но говорить что работать невозможно я бы не стал!
Никто никого не заставлял не хотите — не терпите, свифт можно использовать опционально, а метал как говорят люди которые с ним работаю — технология хорошая, дает прирост в производительности.

Нормальную сделали, на уровень «экспериментально» полностью годится, при желании все можно заставить работать. Это нормальный процесс развития, так развивается меса в линуксе. На счет веб асамбли я все-таки больше склонен верить решению крупных корпораций, поставщиков популярных браузеров, которые уже договорились и своему опыту и пониманию отличия веб есамбли от плагинов, чем вам.

Дед триггер достаточно крупная игра по сравнению с кубом и светом, да и в принципе. race.assassinscreedpirates.com. Есть много демо мобильных игр портированных на вебжл. Работает и в хроме, и в фф, и в опере.

В юнити много мелких команд. И навряд ли компания которая перестроилась на предоставление услуг, а не продаже движка вдруг вымрет.

Не рассматриваем, в процесс не вписывается + мало специалистов по блендеру. Я честно говоря не вижу его ниши (для сайтов — много, для игр — мало), но мне его продвигать и не нужно, это ваша работа.
Для мобильных — есть приложения и это нормальный подход, серьезную сцену, а не просто куб со светом они выдерживают весьма плохо. Что касается Юнити — они готовились сильно заранее, как и продолжают делать с вебжл2 и веб-асамбли. Релиз нескольких крупных игр под вебжл на юнити (например дед триггер и асасин крид) как раз и доказывает его готовность. К тому же большие игроки дают фидбек и поддержка улучшается от версии к версии. Опять же проект серьезно финансируется, имеет рнд команду и постоянно пробует новые функции, потому говорить о том, что их застали врасплох как минимум не корректно.

Вот если говорить про не игровое 3д для сайтов, то тут юнити пожалуй действительно тяжеловесен и лучше пользоваться простыми низкоуровневыми библиотеками типа threejs или babylon (последний не пробовал, но демки впечатляют).
Сочувствую. Да из за превью лезут баги (например с тенями), но в целом все работает корректно. Некоторые люди даже полноценные игры портируют на вебжл. Все возможно — было бы желание =)

По материалам: если пересвет или недосвет — проверьте нормали. Используйте 5.1.1 — она для вебжл подходит лучше всего.
К сожалению, экспортер Unity для WebGL пока не рабочий и нужен иной инструмент.

Он вполне себе рабочий, за исключением пары багов которые худо-бедно можно обойти сцена выходит и по качеству и по размеру сравнимой с релизом под плагин.
Кстати о Unity3D — будет ли работать интеграция с этой IDE?
+0 === -0 даже с точным равенством и тут ничего кривого нет, как и в том, что 1/(+0) !== 1/(-0) или NaN !== NaN.
Вот еще не слишком популярная, но рабочая библиотека для commonjs модулей, умеет подгружать модули синхронно и асинхронно.
Иногда СКА дают не полный ответ (попробуйте решить переопределенную систему уравнений с неполиномиальными решениями), что в некоторых случаях хуже отсутствия ответа вообще, причем они делают это без предупреждения!
Тогда уже лучше посмотрите в сторону slush, он спроектирован для работы с gulp.
Было бы неплохо дать список литературы (сразу наперед)
Да, верно. Посмотрите ещё в сторону gulp, возможно будете усложнять систему сборки и замените им watchify.
Ничем, эти библиотеки решают разные задачи: watchify — пересобирает проект при изменениях, а smoothie — клиентская библиотека для работы (синхронного/асинхронного подключения) с commonjs модулями.
Для тех, кому не нравится каждый раз пересобирать проект — есть библиотека smoothie. Её удобно подключать во время разработки, а уже при сборке — использовать browserify.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность