LINUX.ORG.RU

Blend4Web 17.04

 , , ,


0

1

Вышла новая версия открытого фреймворка Blend4Web, предназначенного для создания браузерных 3D-приложений.

Ключевые особенности релиза:

  • Поддержка контроллеров HTC Vive. Разработчики создали простое приложение, демонстрирующее работу устройства. Там же есть исходники проекта. Учтите, что WebVR — молодая технология и доступна только в экспериментальных сборках браузеров.
  • Поддержка WebAssembly в физическом движке. Это перспективная технология, способная улучшить производительность работы приложений в веб-браузере и уменьшить размер используемых модулей. Разработчики подготовили специальную сборку физического движка Uranium.js (форк Bullet) под WebAssembly. Так как сборка экспериментальная, то по умолчанию она не используется и ее нужно принудительно активировать в настройках.
  • Улучшенная система LOD (Levels of Detail). Используется в играх для уменьшения нагрузки на ресурсы компьютера путем демонстрации копий объектов разной детализации в зависимости от расстояния до камеры. Основной проблемой LOD является видимое изменение качества моделей при переходе на следующий уровень детализации. Разработчики Blend4Web добавили механизм плавного переключения между уровнями. Движок удаляет часть пикселей в зависимости от расстояния, тем самым смягчая переход. Новая опция получила название LOD Smooth Transitions и находится в настройках объектов.
  • Поддержка материалов Cycles. Продолжилась работа по интеграции материалов Cycles в Blend4Web. В этот раз пользователям стала доступной нода Background, которая используется для создания окружающей среды. Также поддерживается нода Environment Texture и анимация материала.
  • Сжатие GZIP. Теперь пользователи могут выбирать способ сжатия ресурсов, либо настраивая веб-сервер, либо используя функции предлагаемые разработчиками.
  • Обновлённый эффект Bloom. Реализован новый алгоритм эффекта Bloom, более быстрый и эффективный, который работает со всеми типами источников света и не зависит от направления освещения.

>>> Подробности



Проверено: Shaman007 ()

Здравствуйте!

А можно ли на вашем движке написать браузерный клиент OpenSim?

anonymous ()

Ну или сделать свою собственную открытую _многопользовательскую_ VR-систему с возможностью загрузки контента самими пользователями. Думаю, если такое появится - это будет прорыв, и Second Life (которой нужен толстый клиент) можно будет закапывать.

anonymous ()
Ответ на: комментарий от anonymous

А можно ли на вашем движке написать браузерный клиент OpenSim?

Разрешаю.

CYB3R ★★★★★ ()
Ответ на: комментарий от CYB3R

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

anonymous ()
Ответ на: комментарий от anonymous

Можно, но не нужно. Проще с нуля всё сделать. Для этого High Fidelity разрабатывается.

Quasar ★★★★★ ()
Ответ на: комментарий от anonymous

Ну или сделать свою собственную открытую многопользовательскую_ VR-систему с возможностью загрузки контента самими ользователями.

High Fidelity. Только оно сейчас немногим лучше себя чувствует, чем проприетарный Project Sansar.

Думаю, если такое появится - это будет прорыв, и Second Life (которой нужен толстый клиент) можно будет закапывать.

У SecondLife как раз наитончайший клиент, так как большая часть всего (объекты, коллизии, физика и т.д.) на стороне сервера обрабатывается - на стороне клиента только графика и звук. И SecondLife фиг получится закопать из-за того, что инфраструктура вся у LindenLab, а следовательно весь контент там же. Если нужен просто Social VR без user-generated content, то есть AltSpaceVR (если честно, говнецо то ещё) и RecRoom (самое перспективное).

Quasar ★★★★★ ()
Ответ на: комментарий от anonymous

Оценка такая: всё будет тормозить и глючить, так как сабж завязан на web и новомодный тормознутый webassembly. Надо как-то систему серверов организовывать или p2p. На базе сабжа это крайне непросто. А p2p метаверс в виде Solipsis уже был, вот только в то время никто не поддержал и потому проект загнулся, хотя вполне рабочий был.

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

тормознутый webassembly

можно с этого места подробнее?

asaw ★★★★★ ()
Ответ на: комментарий от asaw

Это же очевидно был вброс!

Ваш кэп.

anonymous ()
Ответ на: комментарий от asaw

можно с этого места подробнее?

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

и точенее я уже запиливал во время питона2 сравнивал с джавой с джаваскриптом, чисто в рабочих интересах

тем неменее

ЭТОЖЕ ****Ь СУПЕРОЧЕВИДЯНО почему все инетрпретируемое г-но такое тормозное и это вообще никак не фиксится

есть большой кусок данных(текст/текстура/кусок логики с классами и рекурсией/подобное)
который обрабатывается на ЦП так и грузится он таким образом
RAM->кэш процессора->обратно в RAM
и все интерпретируемые языки делают все эти операции просто в ТЫЩИ раз медленнее ибо эти сами языки представляют из себя один болькой КУСОК данных которые сначала нужно прогнать ram-кэш-ram после этого исполнить монстроузный алгоритм сформированный из шаблонов интерпретатора и уже обработать сам алгоритм вашего скрипта с данными

и чем БОЛЬШЕ нужные данные для обработки-тем МЕДЛЕННЕЕ ваш вебасембли/джава/джаваскрипт/питон

тоесть все по прежнему-для показа HELLO WORLD это годиться, для реальных приложений- нет

вон как выше говорят «сделать игру на вебгл»(агалог существующей)-так это невозможно именно по этой причине-что по сравнению с нативным аналогом «вебгл»/вебасембли аналог будет просто невероятно тормозить
любая ААА игра 2000 года(которая использует 1ггц ЦП и 64мб оперативки) портированнаябудет жрать 100% core i7 и пару гигабайт оперативки
возьмите даже уже портированные примеры более старые-тотже квейк3 или хайлфлайф-так они и жрут и выдают струдом 60ФПС
а говорить про игры 2002+ года требующие уже 1.5ггц Цп- так это вообще невозможно

и а если вам нравитсья такой регресс в 2017 играть в игры и смотреть на графон 1998 года- продолжайте хайпить это все браузерное г-но

anonymous ()
Ответ на: комментарий от anonymous

Я в старых темах об этом движке уже писал что двиг тормоз, ибо WebGL в разы медленней, но разработчики рассказали мне что я не шарю.

OpenMind ★★ ()
Ответ на: комментарий от anonymous

А кто тебе сказал, что wasm - интерпретируемый язык? Ты, конечно, можешь его интерпретировать (есть и для C++ интерпретаторы), но вообще «WebAssembly aims to execute at native speed».

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

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

Здесь справедливо ругали WebAssembly - технология ещё сырая, поэтому Blend4Web позволяет её использовать лишь в экспериментальном режиме и только для физики, которая работает в отдельном потоке (worker).

Весь рендеринг и логика написаны на чистом, незамутненном JS с большим кол-вом оптимизаций. Над этим мы много работаем. Вплоть до пересборки Chrome для подсчета кол-ва инструкций в самых часто вызываемых функциях. Конечно, этого недостаточно, чтобы добиться паритета с скомпилированными двжиками, но это позволяет Blend4Web рисовать сцены с большим количеством объектов быстрее прочих WebGL движков, тем более собранных с помощью Emscripten (Unity, Unreal и т.п.) И это особенно заметно, если используется физика.

Если вы запустите практически любое приложение на B4W, то наверняка оно будет упираться в GPU, а не в CPU, если они из одного ценового сегмента.

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

evgeny-ar ()
Ответ на: комментарий от Quasar

High Fidelity. Только оно сейчас немногим лучше себя чувствует, чем проприетарный Project Sansar.

Посмотрел репозиторий — вроде бы активность есть. А какое-нибудь внятное описание архитектуры проекта у них имеется? Что такое domain-server, ice-server... В требованиях есть C++ и Qt5 — это про клиент или про сервер? Или вместо клиента там тоже браузер?

Ну и системные требования слегка опечалили, OpenSim на куда более скромном железе взлетает, несмотря на то, что написан на сишарпе. :) Да, конечно, домашнюю машинку под такое найти вполне можно, но вот доступные по цене VPSки уже не подходят...

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 4)
Ответ на: комментарий от evgeny-ar

Здесь справедливо ругали WebAssembly - технология ещё сырая

Её ругали не за сырость, а за тормознутость, что по моему опыту действительности не соответствует.

asaw ★★★★★ ()
Ответ на: комментарий от asaw

Тут на лоре кто-то проводил тесты вебассембли по сравнению сжпбоскриптом. Две недели они там колдовали, но заставить его работать быстрее жабоскрипта не получилось. Подробностине помню, помню, что не взлетело.

Chelobaka ★★★★ ()

А я как всегда рад за разработчиков. Интересным делом занимаетесь. По хорошему завидую. И вообще, благодарен вам благодарен. Благодаря вашему конкурсу вернулся с того света :)

Успехов проекту. Всячески поддерживаю.

Chelobaka ★★★★ ()

отвечу всем и сразу выше(тотже анонимус)

ШТО што што вы несете

хоть один из вас пробовал ПИСАТЬ на юнити???? а там C# и .net один из самых быстрых интерпретаторов... и на Юнити вы не напишите даже игру функционала близкую к ААА играм 2006 года(шутерам к примеру или РПГ любой жанр чьи игры того года использовали 100% возможности ЦП+ГПУ и были нативными)
ниодна игра 2016 года на юнити ни графически ни по функционалу даже не близка к 2006 году

и почему-да потому что все тормозит в этом юнити и попытки написать динамическую карту подгружаемую-будет лагающее г-но(а вы думали почему ниодна РПГ на юнити не имеет динамической карты подгружаемой) или почему ниодин шутер даже не близок к движку дума3/квейка4 и играм на этих движках, мне напомнить про «Enemy Territory: Quake Wars» и требования системные этой игры?? сравнивать надо?

B4W, то наверняка оно будет упираться в GPU, а не в CPU

просто ФЕЙСЕПАЛЬМИЩЕ я за 5(ПЯТЬ) минут напишу игру «пин понг» и она будет ТОРМОЗИТЬ на этом b4w из за расчета сталкновений на CPU, это я про «кастомную физику самописную»(не вашу физику) где столкновения будут считаться пересечением объектов из GL и весь алгоритм вызовов Gl-джаваскрипт КАСТОМНЫЙ код, я именно про «кривую кастомную физику» которая на C++ будет жрать 15% ЦП и выдавать 300ФПС+ на встроенном видео и 1 ФПС и 100% нагрузку на ЦП на ЛЮБОМ вебгл движке ибо все упрется в ДЖАВАСКРИПТ

И это особенно заметно, если используется физика.

что такое физика? физика частиц на экране каждого пикселя и их столкновения? была написана в 2000 году для 800мгц ПК и работала на 200мгц АРМ в 2004 в реалтайме и ФПС 30
физика-это ПРОСТЕЙШАЯ ЛОГИКА и кода там пару страниц всего
и то что вы приводите столь ПРОСТУЮ логику как выдающееся достижение в 2017 году на текущих мощностях ЦП и ГПУ- это ужасно

А кто тебе сказал, что wasm - интерпретируемый язык?

мои глаза, пожалей мои глаза, дада как скажешь только не пиши ничего больше пожалуйста

anonymous ()
Ответ на: комментарий от Chelobaka

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

Если не получилось заставить работать быстрее, это ещё не значит, что оно работает медленнее. А если оно работает так же, то аргумент о тормознутости снова не применим.

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

и приведу привмер

как будет работать «клон» диабло2(игры) или старкрафт(игры) на джаваскрипте

диабло хранит в памяти карту из «ИД объектов»-это и есть карта динамически прокручеваемая
отображаемые объекты- берутся движком по ИД на «карте» из ресурс файла
и такая логика будет выдавать ЛАГ на 0.5-1 сек каждую минуту как минимум при прокрутке карты-потому что
почему- потому что «логика прокрутки» будет обрабатываться на каждый кадр прокрутки и также переподгружать все объекты по ИД из ресурс файла-это все через рам-кэш_цп-рам
и для джаваскрипта-это в 100x(и больше) раз большая нагрузка на ЦП чем на С++

это так будет работать ПОРТ кода

а как будет выглядеть ЛОГИКА игры старкрафт/диабло2 для джаваскрипта чтоб она не тормозила:
вся оптимизация С++ удалена и вся логика сделана максимально тупо- класс «объекта» хранящий все включая текстуру на все «ИД объектов» и глобальная карта состоящая из классов(тоесть прямых ссылок на данные)-и это будет жрать под 2+ГБ и больше в зависимости от размеров карты и минимум ЦП и выдавать под 60ФПС спокойно

в сравнении с С++ кодом- будет удален весь код по «покадровой прокрутке» будет удален и заменен на «нативную для браузера» прокрутку канваса куда будут рисоваться опятьже самим браузером вся карта(тоесть еще и код рисования зоны на экране удален)

джаваскрипт ставит жесткие ограничения на «стиль написания логики» также как и .net ставит ограничения на C# код и видя что мой проект с «С++» подходом лагает-надо переписывать под ".net" стиль делая «спецефические оптимизации»

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

и производительность джаваскрипт-кода зависит только от скорости копирования рам-кэш-рам...

это все банально для любого кто писал чтото сложнее hello-wold на С++ и джаваскрипте

anonymous ()
Ответ на: комментарий от asaw

Штука, которая по идее, разрабатывалась чтобы работать сильно быстрее жабоскрипта работает иногда также, иногда медленнее, иногда чуть быстрее после долгих экспериментов выжать из неё всё. Это по твоему не тормознутость? А что это? Это фиаско.

Вот блендфовебовцев бы спросить, что у них получилось, бэнчмарки какие посмотреть, им я верю, их я бы послушал.

А ты иди за пруфами, что вебассембли не тормоз.

Chelobaka ★★★★ ()
Ответ на: комментарий от asaw

ахаха, смешно. но не впечатлило. враки.

вот больше похоже на правду

Chelobaka ★★★★ ()

А чо они как убунта, два раза в год? Лтс есть, чо?

TooPar ()
Ответ на: комментарий от Chelobaka

ахаха, смешно. но не впечатлило. враки.
вот больше похоже на правду

То, что яваскрипт делает за 300мс, WA делает за 250мс.

Твой линк прекрасно согласуется с моим и ещё раз подтверждает мои слова, только ты об этом не догадался.

asaw ★★★★★ ()

Обновлённый эффект Bloom

Ага. Был нормальный, а щаз постпроцессинг простой. Выделили яркие участки в финальном кадре, размыли, наложили на финальный кадр. Как в 2001 году

TooPar ()
Ответ на: комментарий от anonymous

и все интерпретируемые языки делают все эти операции просто в ТЫЩИ раз медленнее ибо эти сами языки представляют из себя один болькой КУСОК данных которые сначала нужно прогнать ram-кэш-ram после этого исполнить монстроузный алгоритм сформированный из шаблонов интерпретатора и уже обработать сам алгоритм вашего скрипта с данными

Чувак, ты про JIT что-нибудь слышал?

foror ★★ ()
Ответ на: комментарий от anonymous

диабло хранит в памяти карту из «ИД объектов»-это и есть карта динамически прокручеваемая
отображаемые объекты- берутся движком по ИД на «карте» из ресурс файла

Можешь дать ссылку где про это можно почитать подробнее?

foror ★★ ()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от asaw

почитай комментарии в той теме, пройди по ссылкам, тоже почитай. Где-то есть ещё и вторая тема по этому поводу. Там люди старались, тестировали. Увидь реальную картину.

Chelobaka ★★★★ ()
Ответ на: комментарий от Chelobaka

Реальная картина состоит в том, что wasm ещё просто недостаточно стабильная и зрелая технология - это её единственная большая проблема на сегодня. А ты просто наводишь тень на плетень и сваливаешь всё в одну кучу не разобравшись.

asaw ★★★★★ ()
Ответ на: комментарий от asaw

вот когда его доделают, тогда и встревай, а пока он тормозной.

Chelobaka ★★★★ ()
Ответ на: комментарий от Chelobaka

а пока он тормозной

Это либо ты сам тормозной, либо ты просто читать не умеешь.

asaw ★★★★★ ()

Но WebGL не нужен и убог. Там же даже геометрических шейдеров нет.

buddhist ★★★★★ ()
Ответ на: комментарий от anonymous

хоть один из вас пробовал ПИСАТЬ на юнити???? а там C# и .net один из самых быстрых интерпретаторов... и на Юнити вы не напишите даже игру функционала близкую к ААА играм 2006 года(шутерам к примеру или РПГ любой жанр чьи игры того года использовали 100% возможности ЦП+ГПУ и были нативными)

http://www.kongregate.com/games/tfender/contract-wars

Neurotizer ()
Ответ на: комментарий от buddhist

Но WebGL не нужен и убог. Там же даже геометрических шейдеров нет.

Когда из браузеров выпиливали флэш, юнити и прочие плагины, рассказывали про проприетарное ненужное дырявое поделие и обещали, что сейчас коммунити запилит вебгл лучше всех прежних технологий. Ну и где?

Neurotizer ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.